New revs
Plugin revs »

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: New revs
« Reply #90, on September 11th, 2010, 04:18 PM »
Quote from Arantor on September 11th, 2010, 03:09 PM
Oops, I broke it :P
Told ya I hadn't looked into Class-Editor... ;)
I must say, I'm not too excited about having to type wedgeEditor::preparsecode instead of just preparsecode(), but I'm sure there's a good reason behind it, I trust you on that one. (If there isn't, then I'll kill you dead for it :P)
Quote
Are we going to update changelog.txt?
Well, one of the things that really piss me off with changelogs, is that NOBODY reads them, even when you're trying HARD to make them fun to read... (Just have a look at some of Aeva/SMG/AeMe's log entries. I even placed a Blade Runner quote in AeMe and nobody probably saw it :P)
So, having a 800KB changelog is totally useless in that respect. What people need is the kind of changelog I do for AeMe on big version updates: I categorize changes by interest. The biggest changes are put first, then the "cool" changes, then at the end I have a list of geeky, uninteresting changes, and finally the mandatory line "Plenty of bug fixes as usual", which is totally right.

I generate my changelogs at release time (or close to), by getting them from Tortoise and reordering them.
We could try having a changelog generated automatically from the svn (I'm sure there's a tool for that), and then we can go through it and delete anything that's not of interest to the reader.

Also, one of the things that piss me off in SMF's changelog, is that they document fixes for *unreleased revs*. Yay... Like it's going to be of any interest to non-testers! Even them don't read changelogs -- at best, they go through (most of) the bug tracker.
Quote
Also, did you see my proposed changes for the PM UI? (http://tracker.wedge.org/?sa=ticket;ticket=18.msg253#msg253)
Yes, and that's precisely what got me to find the crash ;) And subsequently the ClassEditor missing a dash.
I was trying to send meself a PM to see if you had committed the change already (I wasn't sure.)
Anyway, yeah, do try and commit it. ANYTHING is better than what's up right now...! :) We'll fix it later if it needs anything.

Really, really -- let's all have fun with Wedge. It's been over 2 weeks now, and it's been a lot of fun already. I can't stop working on it, it's so thrilling to finally be able to get rid of legacy code and add features that have been waiting for so long. And I haven't even got started on converting Noisen features!! ;)

At some point, we'll have to consider posting a working copy of Wedge in private, for our users here. I'm sure they'll appreciate being able to browse through the changes instead of just discussing them. Since we're working on local copies, it won't be updated as often, but it could.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #91, on September 11th, 2010, 08:51 PM »
Quote
(If there isn't, then I'll kill you dead for it )
There is. My argument is, ultimately, that instead of loading a seemingly unrelated file every time you want to handle editor input, you load the editor's code - see, if you're instantiating the editor, you used Subs-Editor.php, but when you handled the editor's input... you load Subs-Post.php. The only logic I can find for that is that preparsecode was originally in Subs-Post.php for SMF 1, when Subs-Editor.php didn't exist.

I liked how you did the AeMe changelog though I'll admit I never read it in detail.

I hadn't committed the PM stuff, I wanted to get opinions on it before I did since it wasn't very cleanly done. I'll commit in a minute and we can pick the bones out of it later.
Posted: September 11th, 2010, 08:30 PM

Revision: 88
Author: arantor
Date: 19:50:12, 11 September 2010
Message:
+ Dropdown selector for PM viewing mode (PersonalMessage.php, PersonalMessage.template.php, PersonalMessage.english.php)
----
Modified : /trunk/Sources/PersonalMessage.php
Modified : /trunk/Themes/default/PersonalMessage.template.php
Modified : /trunk/Themes/default/languages/PersonalMessage.english.php


Note: the strings were copied from the Profile, rather than loading the profile strings. I figured if we like this, we'll subsequently remove the option from the profile area anyway, but for now it's duplicated.
When we unite against a common enemy that attacks our ethos, it nurtures group solidarity. Trolls are sensational, yes, but we keep everyone honest. | Game Memorial

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: New revs
« Reply #92, on September 12th, 2010, 01:03 AM »
* Nao/Gilles is in a trance listening to the Atari ST Chambers of Shaolin soundtrack...
Quote from Arantor on September 11th, 2010, 08:51 PM
There is. My argument is, ultimately, that instead of loading a seemingly unrelated file every time you want to handle editor input, you load the editor's code - see, if you're instantiating the editor, you used Subs-Editor.php, but when you handled the editor's input... you load Subs-Post.php. The only logic I can find for that is that preparsecode was originally in Subs-Post.php for SMF 1, when Subs-Editor.php didn't exist.
I understand that... But what is the logic behind having to call the editor class when preparsing an innocent string for use in parse_bbc()? Nothing says it was added through the editor itself... It could have been imported through a feed, etc... (Or even generated by SMF or a mod...)
Quote
I liked how you did the AeMe changelog though I'll admit I never read it in detail.
Well, that only proves my point :P
I don't believe anyone ever admitted to me having read the changelog at all. It's okay with me. It's THERE to be read if you need to. If you don't, then that's okay. But it's just like buying a new car and thinking, "okay it's cool, I can drive a car already, I don't need to read the manual..." And then of course you realize some things are done differently, then you read the changelog, and discover in the meantime a feature you never knew had been added, so you figure you'll read the entire changelog to spot other hidden features, and all you end up finding is easter eggs... :P

Oh my... Chambers... of... Shaolin... It's so great, I can't focus on this post... Too bad the Amiga version sounds so dull...
Quote
Note: the strings were copied from the Profile, rather than loading the profile strings. I figured if we like this, we'll subsequently remove the option from the profile area anyway, but for now it's duplicated.
Sure!
I'll have a look tomorrow...

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #93, on September 12th, 2010, 01:22 AM »
Quote
I understand that... But what is the logic behind having to call the editor class when preparsing an innocent string for use in parse_bbc()?
When it comes to having it in a random file that seems disjointed, or at least tied to the behaviour in which it is most directly used, I'd rather have it attached to where it is used.

There is no use within SMF/Wedge where preparsecode is used where the content hasn't come from the editor. Sure... it could come from a feed or a mod, but in that case it's still coming from an arbitrary place. As far as I'm concerned, we talking about the function being just in a file, versus being with the code that hands content to it.

For me it's a step towards creating some semblance of order where, right now, I don't really see it.

I'd like to think we can make a useful changelog for people much like the AeMe one, in a way that's fun as well.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: New revs
« Reply #94, on September 12th, 2010, 01:36 AM »
Quote from Arantor on September 12th, 2010, 01:22 AM
Quote
I understand that... But what is the logic behind having to call the editor class when preparsing an innocent string for use in parse_bbc()?
When it comes to having it in a random file that seems disjointed, or at least tied to the behaviour in which it is most directly used, I'd rather have it attached to where it is used.
Fine, but... In an editor object?
Look at Aeva-Media.php... It has the media object in it. See the extList function? I put it outside the object because I was getting errors when running in strict mode (dunno why.) Still, I think it's better in that place because basically it was mainly unrelated to the media object and made no use of it. The function is still in the better file, but doesn't have to be in the object itself.
Quote
There is no use within SMF/Wedge where preparsecode is used where the content hasn't come from the editor. Sure... it could come from a feed or a mod, but in that case it's still coming from an arbitrary place. As far as I'm concerned, we talking about the function being just in a file, versus being with the code that hands content to it.
Is this, anyway, really going to help the adding of TinyMCE, CKEditor etc?
Quote
I'd like to think we can make a useful changelog for people much like the AeMe one, in a way that's fun as well.
Of course we can :) If only for us to keep track of what makes Wedge great!

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #95, on September 12th, 2010, 02:14 PM »
Yes, in an editor object, because the only time I ever actually saw it used outside of coming from the editor was for shoutboxes.
Quote
Is this, anyway, really going to help the adding of TinyMCE, CKEditor etc?
Yes, now the underlying reason. Code that comes from one of those will need some kind of treatment before it can be saved - I don't know about you, but I'm hesitant to trust anything from the user. Don't care what it is, I don't want to trust it without some kind of processing.

I need to sit down and look at exactly what is sent, to figure out what changes are going to be necessary to the preparse routine, but some changes *are* going to be required, and having all the code in one place means it's possible to keep all the related behaviour together.

I'm not sure yet exactly we'll handle the editors, whether we just have one only, or multiple (since that was something YSF wanted), or fix up the WYSIWYG editor in some fashion, so I haven't yet made it trivial to switch behaviours, but having the class structure will make it easier in the long run.
Posted: September 12th, 2010, 01:47 AM

Revision: 89
Author: arantor
Date: 01:17:59, 12 September 2010
Message:
! Change 'stars' to 'rank images' (including renaming the star*.gif files though left the table column alone) (yabbse_to_smf.sql, install_2-0.sql, upgrade_1-0.sql, ManageMembers.english.php)
----
Added : /trunk/Themes/default/images/rank.gif (Copy from path: /trunk/Themes/default/images/star.gif, Revision, 87)
Added : /trunk/Themes/default/images/rankadmin.gif (Copy from path: /trunk/Themes/default/images/staradmin.gif, Revision, 87)
Added : /trunk/Themes/default/images/rankgmod.gif (Copy from path: /trunk/Themes/default/images/stargmod.gif, Revision, 87)
Added : /trunk/Themes/default/images/rankmod.gif (Copy from path: /trunk/Themes/default/images/starmod.gif, Revision, 87)
Deleted : /trunk/Themes/default/images/star.gif
Deleted : /trunk/Themes/default/images/staradmin.gif
Deleted : /trunk/Themes/default/images/stargmod.gif
Deleted : /trunk/Themes/default/images/starmod.gif
Modified : /trunk/Themes/default/languages/ManageMembers.english.php
Modified : /trunk/other/converters/yabbse_to_smf.sql
Modified : /trunk/other/install_2-0.sql
Modified : /trunk/other/upgrade_1-0.sql

(ticket 36)
Posted: September 12th, 2010, 02:18 AM

Revision: 90
Author: arantor
Date: 04:16:31, 12 September 2010
Message:
+ Dropdown user menu added (Display.php, Display.template.php, index.english.php, topic.js)
----
Modified : /trunk/Sources/Display.php
Modified : /trunk/Themes/default/Display.template.php
Modified : /trunk/Themes/default/css/index.css
Modified : /trunk/Themes/default/languages/index.english.php
Modified : /trunk/Themes/default/scripts/topic.js

It's not overly pretty, but I think it's better handled than my original mod; firstly, it doesn't show in wireless when it isn't meant to, and it is now JS controlled, but the JS isn't particularly elegant - and for some reason it's not dropping smf_scripturl into the URL when it begins with ? - I didn't see a need to spell out $scripturl every time in the array. Note that since PHP 5 rather than 5.1 or 5.2 has been stated, I'm using a homebrew limited version of json_encode to pump the array of data.

I also didn't have the catbg header bar I had before, didn't see a need to throw that into the mix as well. Works in FF and Chrome, too late tonight to test any more (or debug that last oddity)
Posted: September 12th, 2010, 05:19 AM

Revision: 91
Author: arantor
Date: 12:41:48, 12 September 2010
Message:
! Actual fix for who's online glitch (removing previous fix too) (Who.php, Who.template.php)
----
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/Who.template.php
Posted: September 12th, 2010, 01:42 PM

-sigh-

I just realised my fix works for those folks who use JS but not for those who don't. Argh, why did they do it the stupid way they did it? (One form, two dropdowns, and never checking between the two sets of values)

Revision: 92
Author: arantor
Date: 13:13:44, 12 September 2010
Message:
! Additional fix to who's online for non JS users (Who.php, Who.template.php)
----
Modified : /trunk/Sources/Who.php
Modified : /trunk/Themes/default/Who.template.php

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: New revs
« Reply #96, on September 12th, 2010, 04:17 PM »
I'm not very confident that we can actually keep both the internal Wysiwyg editor AND add support for others without too much hacking, but I'll let you play with it if you want ;) I wouldn't mind only supporting external editors, myself.

BTW, what tool do you use to do your site-wide searches, and search & replace events?
Personally, I'm with very old tools (outdated?): Super Text Search for searches (supports regex so I kept it so far), and BK ReplaceEm for search & replace.

Also, in PersonalMessage.php:
Code: [Select]
// Changing view?
if (isset($_REQUEST['view']))
{
$_GET['view'] = (int) $_GET['view'];
Is it wanted? $_REQUEST then $_GET? Not logical to me...

On to the boring stuff... (Haven't tested user menus yet. Excited about 'em.)

rev 93
- Removed support for Konqueror. (Load.php, Subs.php, Admin.template.php, Packages.template.php)
- Removed support for some browser version numbers: Opera 9/10, Firefox 1/2/3, as they're not known to have specific issues. Added user agent in $context['browser']['ua'] for modders to get a clean way to search for specific version numbers. (Load.php)
* After looking through Who.php, I realized I'm also an isset-nazi. Starting work on merging isset() && isset() calls together. (Subs-Editor.php, Subs-List.php, Subs-Menu.php, Subs-MessageIndex.php, ViewQuery.php, Who.php, Post.template.php, Wireless.template.php)
+ Added a msnbot (Bing) check in possibly_robot, but it should be useless anyway. Maybe just in case they decide to add "Mozilla" in their user agent string... (Load.php)

rev 94
! I don't know what a profie is... Is it a profitable profile? (Display.php, index.english.php)
- Deleted im_switch.gif. Goodbye, and please don't call, we won't miss you. (im_switch.gif, Help.template.php)
* Spacing nazi (index.css, Display.template.php, topic.js)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #97, on September 12th, 2010, 04:52 PM »
Quote
I'm not very confident that we can actually keep both the internal Wysiwyg editor AND add support for others without too much hacking
Neither am I and that wasn't the plan. The current editor is... broken. So either we fix it or we kill it and replace it a new one. A better one.
Quote
BTW, what tool do you use to do your site-wide searches, and search & replace events?
Notepad++
Quote
Also, in PersonalMessage.php:
Yeah, implemented that one in a bit of a hurry (I think I said it was ugly). Should be $_GET really, and I don't think I did it as a form submit because of the rest of the form on the page. Though perhaps something properly AJAXish would be better? (And more prone to breaking on custom themes). In any case I'm so used to SMF interchanging $_REQUEST, $_GET and $_POST for the wrong reasons :(

Haven't looked at the changes yet, but all sounds good to me.

Nao

  • Dadman with a boy
  • Posts: 16,082
Re: New revs
« Reply #98, on September 12th, 2010, 06:49 PM »
rev 95
! upgrade_2-0.sql file didn't get deleted after an upgrade process. (upgrade.php)
! Fixed Display template showing an error next to a guest poster. It currently links to a dummy URL, will fix when I had proper support for this Noisen.com feature. (Display.php)
* Moved conversation selector from left to center in PM homepage, as it takes less space there and might be placed more logically this way. But am I to talk... (PersonalMessage.template.php)
* Changed possibly_robot again, to use preg_match() and more generic search terms. (Load.php)

(Feel free to discuss!)
Re: New revs
« Reply #99, on September 12th, 2010, 10:25 PM »
rev 96
+ Re-implemented pseudo-'link' for guests in Display page, for alternative themes. (Display.php)
* Tweaked a couple of language entries. (index.english.php)
* Spacing nazi. (ManagePermissions.template.php)
Re: New revs
« Reply #100, on September 13th, 2010, 10:27 AM »
rev 97
* Changing $_REQUEST to $_GET where logic says so. (PersonalMessage.php)
! Class typos. (ModerationCenter.template.php, Packages.template.php)

Next rev will change all <h[34] class="*bg" to remove the bg class, as they're all enclosed within cat/title_bars anyway, and this can be styled accordingly.
Re: New revs
« Reply #101, on September 13th, 2010, 05:17 PM »
rev 98
* Removed catbg and titlebg classes from all h3 and h4 tags, and updated styling to match this. (Class-Editor.php, ManagePaid.php, index.css, admin.css, ie6.css, ie7.css, rtl.css, plus most template files.)
- Deleted title_barIC class, as it's only used in the information center and there's really no point in having a separate styling for it. (index.css, BoardIndex.template.php)
- Deleted catbg2 and catbg3 classes (unused in Curve.)
* Changed header font to Georgia, for a change really. Will change to something else later. (index.css)
@ Warning! index.css is a work in progress -- I'm currently trying to separate legacy emulation of corners into a new file that will be included through JS, and I need some time to make sure it's usable.
@ In non-compat mode, the titlebg class is now a bit brighter. I like it better this way...
Posted: September 13th, 2010, 05:15 PM

rev 99
- Deleted all occurrences of menu_gfx.png (replaced with menu.png and buttons.png files, respectively, buttons.png being called only on non-compat browsers.)
Re: New revs
« Reply #102, on September 13th, 2010, 05:25 PM »
rev 100
* Updated to SMF rev 10105. And Wedge reaches rev 100...
  ! Clean up package servers (PackageGet.php)
  ! Topic moderation logs were not listed on mod report details page. (ModerationCenter.php) [Bug 4419]
  ! 'moderate_board' permission does not really make sense for guests (ManagePermissions.php) [Bug 4460]

(They also included the topic participation patch I offered. Obviously I didn't reinclude it here ;))
Re: New revs
« Reply #103, on September 13th, 2010, 08:53 PM »
rev 101
* Moved border-radius compatibility code to old.css, and loading it dynamically if needed via JS. Bit cleaner... (script.js, old.css, index.css)
- No longer deleting the wrc and rrc classes on old browsers -- only nulling them. (script.js, old.css)

(How's your Tardis search going?)

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: New revs
« Reply #104, on September 14th, 2010, 12:33 AM »
OK, now I'm back from tidying the house (and it's still not finished), I'll sit and review everything, but you HAVE been busy.
Plugin revs »