This section allows you to view all posts where this member received or gave a like to.
1
You mean that you can create inside the language folder an folder "portugese-pt" from where the files can be loaded? I also wondered if that works, would be nice and a more clean way. Otherwise there are so much files in the language folder which is very chaotic.
2
So, I thought I'd share the design of my upcoming theme for Wedge. Since Wedge doesn't have any dark themes yet, I'm taking the liberty of creating one. It's based on 'Wilde'. The design is still in its initial stage which means a lot can change but please do share thoughts as to how I can improve it - that is the whole point I'm starting this thread.
Peace.
Peace.
3
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
4
Also, do you really think that the other forums are showing all their stuff for no reason?
They are getting more and more input from the community, and not just their little private community.
It's not private, is it? Otherwise, why would you be able to post here..?
Yes, there are some reasons not to use something like GitHub, and I for one can not fault you that.
However, saying that one is better than any other, when none of them are truly out there is being too full of oneself and being conceited.
SMF 2.1 isn't, though, but from what I saw of demo sites, I didn't notice anything special about it. It's technically the least interesting between Wedge, Elk and SMF.
Wait until they are out there, for the general public to use and judge. Then we all will see which is best, in the view of those who count: The users.
5
At 63 I am probably the oldest member here and as I was brought up in the pre-politically correct age, I'm going to call it as I see it; if I unintentionally ruffle a few feathers, then so be it.
Firstly, both Nao and Pete should be thanked not only for their tireless work on the Wedge project but for being so forthright and open with each other and with us. Pete's a self-confessed introvert - though you wouldn't know it from his prolific postings - and I suspect it took him a lot of courage to expose his true inner feelings in a semi-public forum; Nao is more garrulous. Both have proven track records as software developers, certainly for SMF type software and both are perfectionists - Nao is well-known for trimming every redundant byte from JS scripts, for example, and his Mahjong game is simply beautiful.
There appears to be some criticism of Pete's fewer code commits whilst Nao commits more frequently. It seems to me that this simply a difference in style: Pete, being more introverted, keeps his code 'close to his chest' whilst he hones and perfects it; it's a matter of pride to him that code he commits works as flawlessly as possible. Nao is more of a 'write-commit-test-edit-recommit' person. Neither of their personal work flows is better or worse than the other, they're just different approaches. But was it really necessary for Pete to feel that he was being treated like some errant schoolboy whose homework was being marked by his teacher and thereby undermine his self-esteem to the point where he feels he can no longer work on the project?
One issue that has cropped-up very recently is that of restricting the customization of Wedge's look and feel. Nao has designed some very attractive themes but - and here I agree with Pete - the only major difference between two sites running Wedge may be the colours employed and that would be a Big Mistake, in my view. It could well be, for example, that a Forum owner doesn't want the standard sidebar to appear in "Message View" and only on the "Board View" ('Home' Page) - that would certainly be my personal preference FWIW.
Given Pete's knowledge, experience and amount of thought he has put into Wedge, as well as his suggestions for making it better, I find it a very sad state of affairs that he feels he can no longer contribute to the project. I truly hope that he and Nao can come to some understanding which would allow Pete to continue participating in an advisory role - if nothing else. And if he does, Nao, I also hope you will listen to him and pay heed to his advice!
As for the gentleman who suggested that Pete should "snap out of it" and "man up", I have nothing but contempt for those remarks and I suggest that you, sir, show some humility and compassion for your fellow man.
Finally, @Arantor: Pete, thank you for your kind words, encouragement and advice last year when I was developing the Slideshow. I still have hopes that you will incorporate it as a Wedge Plug-In!
Firstly, both Nao and Pete should be thanked not only for their tireless work on the Wedge project but for being so forthright and open with each other and with us. Pete's a self-confessed introvert - though you wouldn't know it from his prolific postings - and I suspect it took him a lot of courage to expose his true inner feelings in a semi-public forum; Nao is more garrulous. Both have proven track records as software developers, certainly for SMF type software and both are perfectionists - Nao is well-known for trimming every redundant byte from JS scripts, for example, and his Mahjong game is simply beautiful.
There appears to be some criticism of Pete's fewer code commits whilst Nao commits more frequently. It seems to me that this simply a difference in style: Pete, being more introverted, keeps his code 'close to his chest' whilst he hones and perfects it; it's a matter of pride to him that code he commits works as flawlessly as possible. Nao is more of a 'write-commit-test-edit-recommit' person. Neither of their personal work flows is better or worse than the other, they're just different approaches. But was it really necessary for Pete to feel that he was being treated like some errant schoolboy whose homework was being marked by his teacher and thereby undermine his self-esteem to the point where he feels he can no longer work on the project?
One issue that has cropped-up very recently is that of restricting the customization of Wedge's look and feel. Nao has designed some very attractive themes but - and here I agree with Pete - the only major difference between two sites running Wedge may be the colours employed and that would be a Big Mistake, in my view. It could well be, for example, that a Forum owner doesn't want the standard sidebar to appear in "Message View" and only on the "Board View" ('Home' Page) - that would certainly be my personal preference FWIW.
Given Pete's knowledge, experience and amount of thought he has put into Wedge, as well as his suggestions for making it better, I find it a very sad state of affairs that he feels he can no longer contribute to the project. I truly hope that he and Nao can come to some understanding which would allow Pete to continue participating in an advisory role - if nothing else. And if he does, Nao, I also hope you will listen to him and pay heed to his advice!
As for the gentleman who suggested that Pete should "snap out of it" and "man up", I have nothing but contempt for those remarks and I suggest that you, sir, show some humility and compassion for your fellow man.
Finally, @Arantor: Pete, thank you for your kind words, encouragement and advice last year when I was developing the Slideshow. I still have hopes that you will incorporate it as a Wedge Plug-In!