Show Likes
This section allows you to view all posts where this member received or gave a like to.
1
rev 2345 -- this huge commit is NOT pushed to master yet; I'm pushing it to the byebye-themes branch, mainly to test branching. I may rebase my stuff, although I'll try to avoid that.
185 files changed, 1939 insertions(+), 2828 deletions(-), 169.14 KiB (record beaten! And unlikely to be beaten again :P The actual diff patch size is 717KB, and I'm going to go through it again, yay.)
delete mode 100644 Themes/default/languages/Settings.english-uk.php
delete mode 100644 Themes/default/languages/Settings.english.php
delete mode 100644 Themes/default/languages/Settings.french.php
delete mode 100644 Themes/default/languages/Settings.german.php
@ The previous commit, despite its size, was a joke compared to this one. Removing theme support (while keeping support for 99% of its features with intelligent skinning) saves a surprising amount of code. Most files get a few kilobytes shaved off their size. Everything done by hand (and triple-checked!), but I'm still expecting many things to be broken for a few days/weeks. I'll fix as bug reports come.
* Renamed all $theme variables to $settings equivalents. $theme, the equivalent of SMF's $settings, is gone. Forever. (There are 120 files or something in this commit, I'm not going to list them all.)
* Replaced $scripturl with SCRIPT and 'theme_url/theme_dir' with TEMPLATES/TEMPLATES_DIR everywhere. Lots of fun. Same with images_url/dir and ASSETS/ASSETS_DIR.
* And more importantly, renamed we::$id to MID most everywhere. This is about twice faster, and, I guess, easier to type and remember.
- Removed theme support from a lot of places. Again-- not listing these all. Basically, many areas will now consider there's only one theme, and that's all there is to say. They'll usually accept multiple skins, of course.
- Removed a suspicious $theme['smileys_url'] I couldn't find used anywhere. (Class-Editor.php)
- Removed theme settings page entirely, phew. (Admin.php Themes.php and Themes.template.php, ManageSettings.php, ManageSettings.language.php, and a few others.)
- Removed unused globals as found by the new version of my fix-globals script. (Class-Skeleton.php, Class-String.php, Notifications.php, and maybe a couple others.)
- This $theme['smileys_url'] alias hadn't been used for years. (Class-Editor.php)
- THEMEURL and DEFAULT_THEMEURL have never been used as variables in email templates. Time to go. (Subs-Post.php)
* Replaced $settings['images_aeva'] with just a hardlink to the /aeva assets folder.
* Renamed show_avatars and show_signatures user options to hide_* equivalents, as it used to be in SMF; this was partly motivated by the fact that most user options have a more sensible 'off' default (except for return to post and quick reply, where it makes more sense to enable these), but mostly because it was buggy and I had to fix it.
* Renamed reloadSettings() to loadSettings(). It's never called more than once... (index.php, Load.php)
* Renamed a few variables to use $context instead of a setting. For instance, if you want to play with templates to be loaded, you should now do it with $context['theme_templates']. Although this one will probably go at some point, too. Or be renamed. Or whatever. Also, $theme['output_buffers'] is now in $context. (Load.php, Subs-Template.php)
* Moved path settings from Server to basic settings. Seriously, this never had anything to do with 'database settings', why mix them up together..? (Admin.php, ManageServer.php, ManageSettings.php)
* Rewrote the $boardurl hack for url_parts(). Thus making $boardurl non-changing across the page lifetime. (Subs-Auth.php)
! News sender was incorrectly interpreting {$board_url} as the script URL, i.e. with 'index.php' in default situations. (ManageNews.php)
! Fixed query viewer not redirecting to the correct URL. (ViewQuery.php)
! Fixed thoughts being refreshed (after an Ajax post) in non-mobile mode even when posting from a mobile skin. (Ajax.php, Load.php, Subs-Cache.php)
! Fixed main menu showing error when the login process failed. (Subs.php)
! Fixed a Pete bug in loadEssentialThemeData stuff. Then removed all code related to the bug, including the fix. Because if you've been reading this changelog, I'm sure you won't mind reading an extra useless line. (ScheduledTasks.php)
* Harmonized member table column lists in loadMemberData; this saves something like 3KB, which is that less data the PHP parser has to load every page load. (Load.php)
* Slightly faster JS/CSS cache purging. (Subs-Cache.php)
Now, go ahead, Like like you've never liked a commit before!! Because that means I'm getting closer to a public release :P
185 files changed, 1939 insertions(+), 2828 deletions(-), 169.14 KiB (record beaten! And unlikely to be beaten again :P The actual diff patch size is 717KB, and I'm going to go through it again, yay.)
delete mode 100644 Themes/default/languages/Settings.english-uk.php
delete mode 100644 Themes/default/languages/Settings.english.php
delete mode 100644 Themes/default/languages/Settings.french.php
delete mode 100644 Themes/default/languages/Settings.german.php
@ The previous commit, despite its size, was a joke compared to this one. Removing theme support (while keeping support for 99% of its features with intelligent skinning) saves a surprising amount of code. Most files get a few kilobytes shaved off their size. Everything done by hand (and triple-checked!), but I'm still expecting many things to be broken for a few days/weeks. I'll fix as bug reports come.
* Renamed all $theme variables to $settings equivalents. $theme, the equivalent of SMF's $settings, is gone. Forever. (There are 120 files or something in this commit, I'm not going to list them all.)
* Replaced $scripturl with SCRIPT and 'theme_url/theme_dir' with TEMPLATES/TEMPLATES_DIR everywhere. Lots of fun. Same with images_url/dir and ASSETS/ASSETS_DIR.
* And more importantly, renamed we::$id to MID most everywhere. This is about twice faster, and, I guess, easier to type and remember.
- Removed theme support from a lot of places. Again-- not listing these all. Basically, many areas will now consider there's only one theme, and that's all there is to say. They'll usually accept multiple skins, of course.
- Removed a suspicious $theme['smileys_url'] I couldn't find used anywhere. (Class-Editor.php)
- Removed theme settings page entirely, phew. (Admin.php Themes.php and Themes.template.php, ManageSettings.php, ManageSettings.language.php, and a few others.)
- Removed unused globals as found by the new version of my fix-globals script. (Class-Skeleton.php, Class-String.php, Notifications.php, and maybe a couple others.)
- This $theme['smileys_url'] alias hadn't been used for years. (Class-Editor.php)
- THEMEURL and DEFAULT_THEMEURL have never been used as variables in email templates. Time to go. (Subs-Post.php)
* Replaced $settings['images_aeva'] with just a hardlink to the /aeva assets folder.
* Renamed show_avatars and show_signatures user options to hide_* equivalents, as it used to be in SMF; this was partly motivated by the fact that most user options have a more sensible 'off' default (except for return to post and quick reply, where it makes more sense to enable these), but mostly because it was buggy and I had to fix it.
* Renamed reloadSettings() to loadSettings(). It's never called more than once... (index.php, Load.php)
* Renamed a few variables to use $context instead of a setting. For instance, if you want to play with templates to be loaded, you should now do it with $context['theme_templates']. Although this one will probably go at some point, too. Or be renamed. Or whatever. Also, $theme['output_buffers'] is now in $context. (Load.php, Subs-Template.php)
* Moved path settings from Server to basic settings. Seriously, this never had anything to do with 'database settings', why mix them up together..? (Admin.php, ManageServer.php, ManageSettings.php)
* Rewrote the $boardurl hack for url_parts(). Thus making $boardurl non-changing across the page lifetime. (Subs-Auth.php)
! News sender was incorrectly interpreting {$board_url} as the script URL, i.e. with 'index.php' in default situations. (ManageNews.php)
! Fixed query viewer not redirecting to the correct URL. (ViewQuery.php)
! Fixed thoughts being refreshed (after an Ajax post) in non-mobile mode even when posting from a mobile skin. (Ajax.php, Load.php, Subs-Cache.php)
! Fixed main menu showing error when the login process failed. (Subs.php)
! Fixed a Pete bug in loadEssentialThemeData stuff. Then removed all code related to the bug, including the fix. Because if you've been reading this changelog, I'm sure you won't mind reading an extra useless line. (ScheduledTasks.php)
* Harmonized member table column lists in loadMemberData; this saves something like 3KB, which is that less data the PHP parser has to load every page load. (Load.php)
* Slightly faster JS/CSS cache purging. (Subs-Cache.php)
Now, go ahead, Like like you've never liked a commit before!! Because that means I'm getting closer to a public release :P
2
I posted a long answer over there... Since it's a pre-moderated message (meh), I'm posting it here in case Bloc doesn't approve it...Quote
I'm curious to see how long it will take you to innocently come back to wedge.org and discuss the upcoming release when you didn't exactly have nice words to say about it just last month when you had ViennaBBS to look forward to ;)Quote from Xarcell on August 9th, 2012, 01:19 AM I really hate to hear it Bloc. I was waiting for viennabbs also. I even resigned from Dream Portal. Oh well, it is what it is.
Don't forget about EosAlpha, either...
Bloc, I just wanted to register to make something clear on your forum -- because in the end, it's always about two communities not talking to each other and having preconceived opinions about one another.
So, without further ado:
- Yes, I rejected your last suggestions about Wedge, and no, it doesn't mean I'm a bad guy.
- Yes, Pete and I always have the last word on Wedge. But because we're the decision makers, we also have a huge responsibility to deliver on our word. And I'd much rather be 'powerless' at this point, and not have that responsibility. The stress level would be totally different.
- No, just because I rejected your suggestions, it doesn't mean I rejected you.
- And just because you have ego issues, it doesn't mean we don't respect you either. We do have ego issues, ourselves.
- I'd just like for it to make it clear that I have the utmost respect for your work and your skills, but that I don't think you're being fair -- to us, to your users, and to yourself. If you're going to make ViennaBBS, then do it silently like we did for a year with Wedge. Don't mention it, then say you're giving up, then resuming work, then giving up again. Just say it's something you don't have plans to release before 2015 or something, and people will lose immediate interest, while still trying to follow what you're doing. It'll be less messy.
- If you're going to complain about Wedge, say anything you like because it's a free country (well, France and Norway are free countries anyway), but I can't let you say it's a "developer-centric SMF" that is not thought out for themers. I spent many, MANY months of my life working on the CSS preprocessor for Wedge. It's a work of art in itself. I may not be as good a designer as you are, but I certainly know what designers need to make their life easier. And you even agree yourself to a point -- recently you mentioned how SMF required of themers that they overwrite index.css to replace some stuff in it, and you pushed towards being able to add on top of it. Well, as you know it's a feature that's been in Wedge for over a year and a half now...
So, I'm simply asking of you to be fair to us. We really liked having you onboard. Just because you didn't feel comfortable not having any actual control over Wedge itself doesn't mean we disrespected you in any way. You're in the same position as everyone else but Pete and I... Had you joined the project on day one, it might have been different, but at that point we were already the two-headed entity that became known as Wedgeward and we locked everything for everyone, including our close friends like Dragooon or live627 (who will gradually get more power over Wedge).
We made Wedge because we weren't happy with SMF's direction and lack of commitment of its team, not because we hated the software as it was at the time. Effectively, we left because the SMF team was too narrow-minded per se, what you're accusing us of being. And you were part of the team at the time.
I'm just wondering... What does 'narrow-minded' mean to you? Someone who doesn't think your way?
(Shamelessly inspired from Eugène Labiche's "An egoist is someone who doesn't think about me.")
3
Off-topic / Re: Bitcointalk.org $11k bounty for new forum software
Nao « on May 3rd, 2012, 07:19 AM »
Ignore what?
We're not refusing anything. We are just waiting for mor details... Because obviously Wedge isn't exactly what you think it is.
We're not refusing anything. We are just waiting for mor details... Because obviously Wedge isn't exactly what you think it is.