[Unknown]

  • Posts: 77
Unknown's thoughts on Wedge
« on June 26th, 2011, 10:11 AM »
Quote from Arantor on June 26th, 2011, 12:43 AM
FWIW, Notepad++ offers 1, 2, some of 3 (there's a popup display for the selection of tabs, much like Alt-Tab does but no jump-to-specific-tab-by-number), 4, 5 if you want, not sure about 6, 7 - well, it doesn't fail on 60MB SQL dumps but it doesn't like it much, 9, 11 and 12.
Quote from Nao/Gilles on June 26th, 2011, 07:52 AM
It has 8 too (clone view in tab context menu).
Hmm, it has 4 and 8?  I probably need to look at it again.  Sounds like it has improved.
Quote from Arantor on June 26th, 2011, 12:43 AM
It's not the uber-IDE but I've found it to be a very nice and capable tool, I certainly haven't found it wanting - except possibly for lack of an SVN plugin that doesn't require the SVN command line tools.
So using svn the way it was intended to be used (that is, via command line) is another beneficial feature it has, you say?  Sounds even better.

Heh, the GUIs bug me mainly because they make their own (different) choices than the developers of Subversion itself.  Example: TortoiseSVN iirc commits externals by default, whereas svn commit doesn't.  The correct way is what svn commit does, and I basically have to not use externals at work because everyone else uses the wrong and breaks them if I do (because they use TortoiseSVN.)

Meanwhile svn has excellent help, clean cli UI, and beats msysgit out of the part on Windows.  What more could I ask for?
Quote from Nao/Gilles on June 25th, 2011, 10:39 PM
And what do you think of our work from what you've seen so far? :unsure:
Well, I'm a nitpicker.  I could list a bunch of problems I have with SMF 2.0 in general, and with this, and even with the changes.  Not to mention just as many with code that is more or less certainly still code I wrote.  I also see it (and probably SMF 2 as well) as even more bloated than before, which I know you probably don't see as a bad thing...

Likely, I'm sure some people thought "my secret project" was bloated, what with its child boards and templates for each section (rather than just one global), etc.  So I'm certain I'm biased.

Anyway, staying away from the details, looking at the code (whether the new Wedge stuff or old) just makes me want to clean it up.  I don't know if you know, but I had a policy of re-reviewing files, periodically (on top of reviewing all incoming commits) which I did by marking files every X weeks and going through them line by line and making sure the code still jived together.

Are you guys doing code review at all yet?

Also, having managed sites that actually had multiple and seasonal themes, and enjoyed it and themes like the Comic theme, the direction I see those going saddens me.  Having written large scale modifications (which if I did it over again, I'd just make it take .diff files directly, in addition to a reasonable set of hooks, but then, the realities of PHP 4 got in the way of many things), and supported people who had very customized versions of SMF and YaBB SE, the direction that's going also greatly saddens me.

FWIW, if you wonder why I like the package manager, just so you know - the reason I joined the YaBB SE dev team was to improve the package manager and put it into Trinity (YaBB SE 2.0.)  Otherwise I would've never joined.  I like the concept of diff updates and being able to keep records of your changes (not that I don't like and desire plugins additionally, e.g. TOX-G is designed specifically with plugins in mind.)

And there I speak about SMF and Wedge, although in different ways.  I realize the "mods are only minor things" and "all themes are just colors changes of the default one" concepts come from somewhere.  Seems like a... not catch 22, whatever it's called when you assume a problem doesn't exist, because you don't have it, but really you don't have it for other reasons.  Seems like one of those whatever-they're-calleds to me, but that's just my opinion.

By the way, I suggest completely replacing setup_fatal_error_context() type operations with exceptions, since if you're requiring PHP 5, this will make integration much easier.  This was one of the big problems with SMF back in the day because of the PHP 4 requirement.  It's why lines like these exist:

Code: [Select]
trigger_error('Hacking attempt...', E_USER_ERROR);

Because I was working so hard to stop people from neutering their own forum's security measures.

Ah... just memory lane, mostly, for me.  Doesn't look different enough, just has stuff like PayPal all over it, which certainly makes the calendar look as much like a core feature as the "Reply" button.

-[Unknown]
Re: Unknown's thoughts on Wedge
« Reply #1, on June 26th, 2011, 10:35 AM »
Quote from "[Unknown]" on June 26th, 2011, 10:11 AM
Hmm, it has 4 and 8?  I probably need to look at it again.  Sounds like it has improved.
Show-stopper: I can't drag files into it to open them.

Find and mark looks like a nice feature, though.

-[Unknown]

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Unknown's thoughts on Wedge
« Reply #2, on June 26th, 2011, 11:33 AM »
Some interesting thoughts there.

In absence of anything else, the package manager means mod authors have to do direct edits to achieve things, rather than making use of facilities available. The main consequence of this is mods doing template edits which cause support issues because they then don't appear on some custom themes, or at least not the way they were intended. Adding to that, any theme that does do anything creative invariably fails, which is why so many themes are basically Curve knock-offs as opposed to anything more daring. (Yes, there were designers who do more daring things, but the vast bulk of the time the theme is just recoloured.)

And while there are some huge mods out there (Nao and Dragooon's Aeva Media, SimpleDesk by me and a couple of others, plus the portal mods), the vast bulk of mods are not that huge. There are mods now that simply remove the XHTML and RSS links from the footer, for example.
Quote
Seems like a... not catch 22, whatever it's called when you assume a problem doesn't exist, because you don't have it, but really you don't have it for other reasons.
You wonder if we're falling into the trap of "solving the wrong problem" as I tend to call it... well, the core reasons are pretty much as above. I know that's one of the reasons Bloc was so adamantly doing his own thing, but even there if you look at his custom themes (even his paid ones), they're still generally not that different, because he knows the reality of how many mods don't work on custom themes, and the support boards are full of it.

The lack of premium ecosystem for SMF also tells me there's a problem. There are currently two sites that I'm aware of, that provide paid-for themes (Bloc's site does not any longer). For a platform as entrenched as SMF is, there should really be more by now, but the fact is that there's no incentive for premium designers to design for SMF. Couple that with the fact that most people seem quite happy with vague recolourings with their own logo (which often doesn't really fit), and you begin to realise that the standard state of play is to run with what there is, rather than doing anything new.

As for mods, the situation there is marginally healthier, indicating that people generally would rather have new features than themes (at least, there is more effort put into mods than there is in themes, in general)

For example, just glance through the last submitted mods to the mod site:
* adding a user's birthday to their profile summary (in addition to the date which is there)
* specifying an alternative email address for outgoing mail, so that the admin's email isn't used for notifications
* a bugfix for the IE8 jumping text box problem, because obviously that couldn't have been added to 1.1.14/1.1.15 or similar
* two different mods for adding the Google +1 button, one for per-topic, one for per-post
* a nice FAQ mod
* a mod to replace the stats area at the bottom of the board index with a jQuery-based tab solution (which means adding jQuery, and will fail on any other theme/mod that already added jQuery)
* a mod to add several symbols as editor buttons (like 1/2, 1/4)
* putting the page number in the title of the page

As you can see, there's a couple of more complex mods, but for the most part there's nothing really that complicated or large in there. Over the three months I was on the Cust team, reviewing mods, the vast bulk of what came in were certainly in the 'small tweaks' category.


I would note that I have spoken to various theme and mod authors over the last two years and I'm hearing corroborating comments on the above. It boils down to the fact that there aren't the facilities to do most things without template changes, and if there were less template changes required, designers stand more chance of doing things that aren't just recolourings. It'll still happen, of course, but by removing one of the barriers that causes it, it should be possible for theme authors to do more interesting things, and by our approach of disallowing file edits from the add-on manager, modders will have to do things through hooks and other established methods - which means they won't be faced with having to do template edits.

That means if a particular mod and a particular theme don't play nicely, it's not related to the systemic issues currently in SMF and its environment, but it's that the theme does something the mod didn't expect, or vice versa - but it means that it can be dealt with on an individual basis. (Even WP has issues in this direction, I would note)
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

[Unknown]

  • Posts: 77
Re: Unknown's thoughts on Wedge
« Reply #3, on June 26th, 2011, 01:22 PM »
Quote from Arantor on June 26th, 2011, 11:33 AM
In absence of anything else, the package manager means mod authors have to do direct edits to achieve things, rather than making use of facilities available. The main consequence of this is mods doing template edits which cause support issues because they then don't appear on some custom themes, or at least not the way they were intended. Adding to that, any theme that does do anything creative invariably fails, which is why so many themes are basically Curve knock-offs as opposed to anything more daring. (Yes, there were designers who do more daring things, but the vast bulk of the time the theme is just recoloured.)
Definitely.  And this is a large problem.  However, fixing it by accepting the poison (of no one doing anything interesting) seems like a bad solution to me.

It's kinda like if PHP had say, "ah, PHP 4 classes suck, so no one uses them.  Got it - let's just remove them in PHP 5."  Who knows what might have happened to PHP had they done that.  Would it have been the right move?  Honestly, can't say, I've heard good things about aspect based programming.
Quote from Arantor on June 26th, 2011, 11:33 AM
And while there are some huge mods out there (Nao and Dragooon's Aeva Media, SimpleDesk by me and a couple of others, plus the portal mods)
Well, a mod like my "wikilinks" mod could easily be made with plugins, as could the calendar and all of the other large, but very separate things you mention.  However, something like an "RPG/Shop" mod (a constant request, or at least used to be) is somewhat more specialized and can't always be done via hooks.  And there are also a ton of little things (small customizations I was paid to do in some cases, for example.)

You can build hooks for any feature, but too many hooks, and the system is confusing and the documentation is miles long.  I know early on we discussed hooking (in PHP 4) manually every function before/after, and there were a lot of concerns, including performance, which can matter a lot to people with huge forums like e.g. Ben_S.
Quote from Arantor on June 26th, 2011, 11:33 AM
they're still generally not that different, because he knows the reality of how many mods don't work on custom themes, and the support boards are full of it.
Well, sure.  Fixing that is a separate issue, though.  Overreacting to a problem by fixing it too many ways is a bad fallacy.  I call it the pendulum: if you look at anything, you'll see humans overreact throughout history.  Art history is a fairly good and clear example of this.  And look and computers: years ago it was all mainframes and terminals, then it went hard toward personal computers, and now it's the cloud and browsers.  You're crazy if you think browsers and terminals aren't, essentially, similar concepts.

That said, you'll always get some similarly.  That's just UX.  You can't build a completely different interface and expect people to understand it.  But you can build a snazzy one that builds on the concepts users know and have used elsewhere.
Quote from Arantor on June 26th, 2011, 11:33 AM
The lack of premium ecosystem for SMF also tells me there's a problem.
Sure.  In part, this is probably because building package servers is just plain not documented.  I was completely expecting to see something like the dag rpm repo happen, and never wanted to manage mods to the scale SMF ended up doing.
Quote from Arantor on June 26th, 2011, 11:33 AM
As for mods, the situation there is marginally healthier, indicating that people generally would rather have new features than themes (at least, there is more effort put into mods than there is in themes, in general)
I dunno, having looked around a bit on occasion to help people, I found it very fragmented.  I agree that SMF doesn't have an effective set of themes or mods.
Quote from Arantor on June 26th, 2011, 11:33 AM
For example, just glance through the last submitted mods to the mod site:
* adding a user's birthday to their profile summary (in addition to the date which is there)
* specifying an alternative email address for outgoing mail, so that the admin's email isn't used for notifications
* a bugfix for the IE8 jumping text box problem, because obviously that couldn't have been added to 1.1.14/1.1.15 or similar
* two different mods for adding the Google +1 button, one for per-topic, one for per-post
* a nice FAQ mod
* a mod to replace the stats area at the bottom of the board index with a jQuery-based tab solution (which means adding jQuery, and will fail on any other theme/mod that already added jQuery)
* a mod to add several symbols as editor buttons (like 1/2, 1/4)
* putting the page number in the title of the page
In order:

1. I don't see why this shouldn't be a "mod", if you will, just one that applies equally to all themes (if the theme has a facility for showing that type of user information.)  This is the sort of problem I tried to fix with TOX-G.
2. This seems like a good candidate for a core feature.  Ideally, it should be built to that standard (I'd always wanted to see features "baked" as mods before going into the core, not sure if that ever happened.)
3. Bugfix mods make sense IMHO.  Easy to remove and then install the official update later.  Hard for hooks to do this.
4. See #1.
5. This definitely seems like hook territory.  I assume it's got its own area and doesn't touch other sections.
6. This is a harder problem, but if it uses jQuery.noConflict it shouldn't cause issues even if there's a separate version of jQuery on the page.  That said, a consistent js framework is a good idea.
7. Sounds like hook territory.
8. Sounds like a fairly basic mod that has no theme problems.
Quote from Arantor on June 26th, 2011, 11:33 AM
Over the three months I was on the Cust team, reviewing mods, the vast bulk of what came in were certainly in the 'small tweaks' category.
See, here's where we get to the actual problem.

Now, at work we build iPhone apps.  Not the main thing we do, but one of the things.  We've made a handful of them.

Generally, we tell our clients: don't make an iPhone app.  Make a mobile HTML5 app.  They are better.  You don't have to deal with Apple's review processes.  They will slow you down, and possibly reject your app for even business reasons.  Don't fight that battle, just make an HTML5 app.

I think the reason for small tweaks being the most common kind of mod is that the whole review thing scares away mid-sized mods.  From your description, and what I've seen, there are "large" mods (which are really almost separate projects glued into the forum), and tiny mods.  Where's the mid-sized ones, which seem (or seemed in the past) abundant with vBulletin and phpBB, where you have to follow manual file editing instructions?  Why do those softwares have them, but not SMF?  Is it because SMF doesn't have enough hooks?

Caveat: I haven't really looked at vBulletin / phpBB mods in a while.  The company I work for will sometimes use them (or write custom ones for a client), but the developers decide that and I've never had to get involved.
Quote from Arantor on June 26th, 2011, 11:33 AM
That means if a particular mod and a particular theme don't play nicely, it's not related to the systemic issues currently in SMF and its environment, but it's that the theme does something the mod didn't expect, or vice versa - but it means that it can be dealt with on an individual basis. (Even WP has issues in this direction, I would note)
Everyone does.  But, supposing Wedge gets popular, I predict zip packages of files to either replace (ala osCommerce "mods"), or txt files/forum posts with manual editing instructions.  Hooks cannot possibly solve every thing a mod ought to be able to do, and if they are really enforced, you're only relegating to always being in the situation of large only-just-touching mods and tiny tweak mods.

And I find it ironic that a while ago someone was complaining that SMF banned bugfix mods, which clearly would not be possible with hooks (how does one fix, for example, a hook not firing when it should by way of hooks?)

* "[Unknown "]takes a moment to say he did not intentionally hijack this topic.

-[Unknown]

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Unknown's thoughts on Wedge
« Reply #4, on June 26th, 2011, 01:41 PM »
Quote
* "[Unknown "]takes a moment to say he did not intentionally hijack this topic.
Not a problem, the things you said are a good argument and worth a read.

Your iPhone app raised my eyebrow, mostly because I need to do something similar. Are the HTML5 apps made to be accessed by the browser, made using something like Sencha Touch, jQuery Mobile or jQTouch, or are they bundled into something like Phonegap to be treated like native apps?
The way it's meant to be

[Unknown]

  • Posts: 77
Re: Unknown's thoughts on Wedge
« Reply #5, on June 26th, 2011, 02:09 PM »
Quote from Dragooon on June 26th, 2011, 01:41 PM
Your iPhone app raised my eyebrow, mostly because I need to do something similar. Are the HTML5 apps made to be accessed by the browser, made using something like Sencha Touch, jQuery Mobile or jQTouch, or are they bundled into something like Phonegap to be treated like native apps?
Well, while I say we recommend against it, we've ended up building native apps in most cases.  Mostly because the client wants to be in the app store (but honestly, I personally am not really sure how much that's worth.)

The review process isn't horrible, and we actually like it internally - because they can give us good feedback.  But it's a danger for the client, because it means timeline and even scope can be affected by another entity.  And since that's what they're paying us for, that's why we need to make the recommendation.

Still, what this ends up doing is making the client pull back on their wants for the app.  Even larger clients, they phase it out a lot.  So the apps are smaller.

Apps on Facebook are a bit more "healthy" IMHO.  They come in a better gradient of sizes (even though they still are often cheesy.)  There's no enforced review process, but if you break the rules, you'll get reported.  In fact, they're much harsher than Apple, as Apple is more willing to work with you, and Facebook will toss you to the curb (and then maybe talk to you.)

Of course, neither platform is really "unhealthy" and Facebook has its own set of problems for sure.  And they both have some of the traditional problems of centralized application repos.  There are also a ton of other things that may be more responsible for their differences, not the least of which are things like screen real estate.

-[Unknown]

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Unknown's thoughts on Wedge
« Reply #6, on June 26th, 2011, 02:13 PM »
I agree with avoiding app store review process, mostly because I don't know how to make native apps(Never learned Objective C). Hence the reason I asked how you guys conceive HTML5 apps.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Unknown's thoughts on Wedge
« Reply #7, on June 26th, 2011, 04:01 PM »
No worries about derailing the topic. I think it's important we have this conversation, really! :) This is going to be a long reply, sorry!
Quote
Bugfix mods make sense IMHO.  Easy to remove and then install the official update later.  Hard for hooks to do this.
I'm not opposed to bugfix mods, per se. The fact that someone bothers to find a bug and post a fix is, on the whole, a good thing. I brought it up before, because it's one of the many infuriating things, that they can't seem to agree on a policy and actually stick to it.

In the SMF climate in particular, and in similar other climates, it indicates a few less desirable characteristics:
1. If your community is producing bug fix packages, we have to ask the question why aren't being made part of the core product?

Is it because your release schedule is far too long and people need the bugs fixed before you can/will get a new version out? Or is it because for some other reason, you're actually not going to incorporate that patch into the core?

In the case of the IE8 jumping text bug, having a mod submitted by one of the core dev team, rather than actually fixing it in trunk (considering that, in the timeframe of a matter of days, a patch to 1.1.x was actually released) - I cannot see any justification for *not* patching it.

2. It discourages people from upgrading. To me, an upgrade shouldn't just be about fixing problems, it should be an overall iteration on what was there before, so improvements (not necessarily new features, but improving existing ones) as well as fixing bugs.

I was amazed how many people weren't upgrading to RC5 because of a bug in RC3/4 and that they thought it was sufficient to use the small patch rather than actually doing the upgrade. Some of those people won't upgrade to final even though it has security-related changes.

I don't exactly want to encourage bugfix mods, which won't be possible with just hooks anyway, if nothing else it means that something else is wrong in the development process.
Quote
Definitely.  And this is a large problem.  However, fixing it by accepting the poison (of no one doing anything interesting) seems like a bad solution to me.
Oh, I'm not accepting the poison. Having spoken to as many people as I can on it, the one factor that seems to be causing it predominantly is mods, and that with having to 'dumb down' what they do because of kow-towing to mods, I went the other way. By making it so mods aren't able to touch templates, or at the very least, if they do (through TOX-G), they can do so non-invasively, that hurdle virtually ceases to be a hurdle.

I accept there are uses for direct file edits, but the more I think about it, the harder I find it to justify having direct file editing as a base feature.

The biggest problem with it is that it promotes a certain level of being lazy. For instance, there was a mod that set up a default avatar. The quickest route for most authors to implement that would be a template edit - with all the problems that brings, and far too few authors would have implemented it in loadMemberContext - though it did happen eventually.

Most of the mod authors are not strong programmers, and invariably look for the easiest route to implement something, which means template edits in the first line of attack, source edits in the second, and almost never taking advantage of the resources actually in SMF to pull some of it off.

It's only since RC4 and RC5 that we're starting to see authors actually take the time and effort to figure out smarter ways of implementing mods, i.e. using the expanded hooks now in SMF. (It's still broken, structurally, but it's a lot better than it was.)
Quote
It's kinda like if PHP had say, "ah, PHP 4 classes suck, so no one uses them.  Got it - let's just remove them in PHP 5."
Not to me, it's not. The comparative statement would be "ah, PHP 4 classes suck, so no one uses them. Why does no-one use them?" IOW, start by figuring out why no-one uses them, what is it they're after, what is it about the current behaviour that's broken?

When I asked myself the same question about the package manager, about what was broken, about what I wanted to see it capable of, I came up with the following:
* File permissions, and making files writable to PHP, is one of the single most asked questions on the support boards -> can we make mods that don't need to make the core files writable?
* Mods only working on certain versions, people asking whether mods will be updated -> does a mod expressly have to ask for a version, or can it attempt to determine if all the features it needs are available?
* Mods searching for code and not finding it, because the original code has been modified (either by a later version, wherein even the comments get modified sometimes, or by another mod) -> can we make mods that either don't need to modify the files, or can better manage to sort themselves out without having to trip over each other?
* Mods that need to modify templates -> why do they need to modify templates? Does it always have to be a template edit, or is it about the data the templates output? Can content be injected into a template in some other fashion?

The first one screams hooks. The second works better if hooks are available because you can even do detection then based on an add-on requiring certain hooks in order to work, and if they're not available, it won't work. The third just generally pushes away from editing files in general, and the last implies something like TOX-G.

It wasn't entirely a knee-jerk reaction as Nao could probably confirm; originally I planned to make the package manager be able to handle more, like registering hooks and so on from the get-go without having to dive into making an installer script, but the more we talked about it, the more I felt comfortable abandoning file edits in the base.
Quote
However, something like an "RPG/Shop" mod (a constant request, or at least used to be) is somewhat more specialized and can't always be done via hooks.
It does come up regularly enough. I'm not sure what you couldn't do with strategic insertion of hooks, it doesn't need to be insane.
Quote
Fixing that is a separate issue, though.  Overreacting to a problem by fixing it too many ways is a bad fallacy.
Or, as I tend to find, you're solving the wrong problem: the solution applied is right for a different problem to the one you thought you had. I don't honestly think the approach I'm pushing for is wrong. It has pros and it has cons, like everything else, and I believe that overall, the pros outweigh the cons more than in the current scenario.
Quote
Sure.  In part, this is probably because building package servers is just plain not documented.
It's not that hard to figure out. But premium sites can't use it because by definition everything in a package server has to be accessible by a simple GET and as far as I can tell, without any authentication handling.
Quote
I dunno, having looked around a bit on occasion to help people, I found it very fragmented.  I agree that SMF doesn't have an effective set of themes or mods.
To me that's a consequence of everything else: all the stuff we've talked about here, seems to me to discourage creators from creating new big stuff, and to a lesser degree, new little stuff too. I would note that all the big projects (the portals, Aeva, SimpleDesk) almost without exception go back 2+ years - SimpleDesk is the only really sizeable mod that turned up in 2010 from what I remember, though there are a handful of modestly sized mods (such as the WP user integration or SimpleSEF) from the same sort of timeframe. What I'm getting at is that the big stuff goes back and the smaller stuff is what's emerging - no doubt 2.0's slow dev cycle was a major factor in that too, with no-one really willing to contribute anything until 2.0 final came in, with all the retesting and updates required for each RC.

The thing most people seem to forget is that the bulk of mod authors aren't people just writing stuff to give away - they tend to write it for themselves and their site, then share.


Going back to the list of mods in particular:
Quote
1. I don't see why this shouldn't be a "mod", if you will, just one that applies equally to all themes (if the theme has a facility for showing that type of user information.)  This is the sort of problem I tried to fix with TOX-G.
It's a tweak, changing the existing behaviour. It's not really a 'new feature', is it?
Quote
2. This seems like a good candidate for a core feature.  Ideally, it should be built to that standard (I'd always wanted to see features "baked" as mods before going into the core, not sure if that ever happened.)
This is a particularly weird case. It is actually a core feature, just one that has no admin interface and is undocumented. All the mod package does is provide that interface in the admin panel. (It's been a core feature for years, too.)
Quote
3. Bugfix mods make sense IMHO.  Easy to remove and then install the official update later.  Hard for hooks to do this.
See above. If you have to accept bugfix mods, there needs to be a reason why they're not in the core, especially when they affect a lot of users.
Quote
4. See #1.
The Google +1 button is in between being a 'tweak' and being a new feature of sorts. And any such change, where it is per post, seems to me like it's tweaking the layout and presentation - and an ideal candidate for something like TOX-G, rather than having to modify any code.
Quote
5. This definitely seems like hook territory.  I assume it's got its own area and doesn't touch other sections.
Yes. It's even implemented actually using hooks, too.
Quote
6. This is a harder problem, but if it uses jQuery.noConflict it shouldn't cause issues even if there's a separate version of jQuery on the page.  That said, a consistent js framework is a good idea.
jQuery is a core feature in Wedge and is slated to be in SMF 2.1 too. But it's slightly awkward that there's no facility to figure out what JS is being included and whether you need to include it yourself. (This is possible with Wedge.)
Quote
7. Sounds like hook territory.
Or better IMO, make the editor buttons configurable to the admin, so if they want to add them, they can. But yes, this could be achieved with hooks (even in SMF) and I don't think it is.
Quote
8. Sounds like a fairly basic mod that has no theme problems.
Well, I'd personally debate that it should be a core feature rather than a mod.


I get the feeling that we're never going to entirely agree on this, but where we're coming from, I think we both feel justified in the stance we take - and are prepared to defend that if necessary. I don't feel uncomfortable with kicking out file edits off the bat, because if they're actually needed, the mod author who needs to use them can document them and deal with it.

The other thing is, a number of the popular SMF mods, I'm going to be writing equivalent (not necessarily replacement) versions of, and making them available, so I'm also making sure the system is capable of the things that I want it to be able to do; I'm not just designing this in some hypothetical vacuum of what it should or should not be able to do, I'm actively building it for my own use as much as anything else.
Quote
I think the reason for small tweaks being the most common kind of mod is that the whole review thing scares away mid-sized mods
I'm not sure it does, to be honest. I think it's more systemic than that. The mods that are big and scary (SP, TP, Aeva, SimpleDesk etc.) all have one common thing: the actual code editing SMF is relatively small, and everything else is in their own files. Meanwhile the mods that are small are just pure code edits (except for the few that are now hook-only).

You mention phpBB and vBulletin... I thought phpBB mods were still, basically, find/replace instructions. (A cursory examination of the phpBB site seems to bear this out but it is strictly a glance rather than a proper study)

As for vB, I have no idea, never used it as an admin, never particularly wanted to.

But I've seen even large-scale phpBB mods done, well, as lists of file editing, which says to me either there aren't hooks, or they're not really in use much.

I'm not sure why SMF doesn't have much in the mid-range, but I'm fairly sure it's not the review process. Small mods are fine with the find/replace approach, but larger mods invariably tend to need more changes and after a point it becomes too much of a pain to maintain with all the changes, and/or they start outgrowing the confines of doing it like that and start needing their own files.

That all said, I'm willing to bet that part of the problem is simply that most mods are contributed by people in their spare time, without any interest or desire in writing big and complex mods - they wrote things for their own site(s) and leave it at that. They don't need or want big and complex mods, so they don't write them. Which also comes back to the lack of premium contributions - what I've seen tends to be that paid mods come into a market first then free competition springs up in response, but SMF didn't really go over that tipping point.
Quote
Hooks cannot possibly solve every thing a mod ought to be able to do, and if they are really enforced, you're only relegating to always being in the situation of large only-just-touching mods and tiny tweak mods.
I agree, to a point. The thing is, apart from the fact that it doesn't seem to have hurt MyBB or WordPress (and especially WordPress), I'm not convinced it will restrict to large or tiny mods. As I've proved before now, all kinds of curious things can be done with some ingenuity even in the current SMF environment (like, for instance, adding multiple helpdesk departments as boards to the board index, but using a custom icon, custom description and link and so on - without a single template edit, even if it is woefully ugly because the structure just doesn't support it normally)

There is one overriding factor here. SMF and some hooks and a hook manager won't be enough. It won't solve the problem at all to do that.

For example, permissions. It's easy enough to add new permissions provided all you want to do is add new permissions for per-board profiles or to a group generally, but anything else, you have to implement it yourself from scratch. Aeva, SimpleDesk, Project Tools and others have had to do this, because the existing system only lets you expand it in one dimension when it needs to be able to provide for two - even if it only barely uses the second dimension itself.

Or, the board index as I mentioned above - there's no reason why there couldn't be an expansion of the board index, not only to be able to understand the board structure and hierarchy but also to have some awareness of the *type* of board, so that new things can make use of it if they want.

That's really what we have to do: just expanding hooks on its own won't be enough. We have to make everything else be more open to extension too, and upon doing that, almost anything should be possible.

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Unknown's thoughts on Wedge
« Reply #8, on June 26th, 2011, 08:46 PM »
Quote
To me it seems Wedge has already been laid out with that lesser possibilities for me as a designer, while SMF is still "full on"...although its focus on CSS-only themes takes away the focus on getting mods out of themes. But at least you CAN still change any template, luckily. I do remember Nao mentioned that it can be done in Wedge too, so its not all bad - but focusing on stylings sends a powerful signal out to any starting designer for Wedge.
Wedge's theme system is only beyond SMF's, it doesn't remove any of the previous possibilities but has enhanced capability for additional css variations.
Quote
But I also see WHY Nao/Arantor wants more features in - more powerful, central developing point etc. I think thats a slightly wrong turn though. Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
Personally, I think it is a more positive turn. Not only does it ensure a system that is powerful and well integrated down to the core, it adds more capabilities for a small time modder to extend upon. It may discourage alternatives, but it doesn't necessarily prevent them. Instead, it helps to improve the existing system with multiple people pouring in.

Nao

  • Dadman with a boy
  • Posts: 16,079
Re: Unknown's thoughts on Wedge
« Reply #9, on June 26th, 2011, 09:03 PM »
We aren't focusing on Stylings. I just offer them as an easy alternative for non modders who want to have different themes for their users without making it a hassle to maintain.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Unknown's thoughts on Wedge
« Reply #10, on June 26th, 2011, 11:24 PM »
Yes, there are mods that modify the moderation centre, or at least affect it in some way. It's not really a good example though.

Thing is, you mention about mods doing the same as existing... Yet why are there only two gallery mods for SMF? The argument is the same, really.

[Unknown]

  • Posts: 77
Re: Unknown's thoughts on Wedge
« Reply #11, on June 26th, 2011, 11:30 PM »
WARNING: Haven't red Bloc's reply or Arantor's follow up yet.  However they are quoting other things I haven't read either, so I'm a bit confused.  I'm going to back up and re-read the whole topic, but I figured this reply still probably stands.
Quote from Arantor on June 26th, 2011, 04:01 PM
1. If your community is producing bug fix packages, we have to ask the question why aren't being made part of the core product?
The kernel has patch sets.  PHP has them too - even though PHP has defined extensions, which are more common.

Open source is all about the community producing bug fix packages, and having a way to "bake" a fix before it going into the core is a very good idea.  Mozilla and other vendors do a lot to offer and maintain several concurrent branches to manage this - but since PHP is source based, the package manager is a much more natural method.

Certainly if the bugfixes are long lived, it's a problem.  When I had my bug fix mods, they only lived for maybe < 1 week until YaBB SE 1.5.1, and then I think 1.5.2 came out.  But people loved them nonetheless.

FWIW, one of the things I would do differently now - before, I would often post on support like this:

Open XYZ.php, search for:
Code: [Select]
abc

Replace with / Add before / Add after:
Code: [Select]
xyz

[[How do I modify files?]]

Whereas nowadays I would probably do this instead:

$ svn diff -c 1234 | smf_diff2modxml | smf_package unknownbrackets:fix_1234 "Fix for XYZ" --versions=2.0 > fix_1234.zip

And just give that to them, with e.g. [[How do I use a bugfix package?]] which would note their removal during an upgrade.
Quote from Arantor on June 26th, 2011, 04:01 PM
I cannot see any justification for *not* patching it.
Sure.  But release schedules happen, and frankly unless it's high-priority, I wouldn't release a new version within 1 week of the other, so as to collect other bugfixes.  Maybe, if some are really hard to fix, even 2 weeks.  While people like software that works, they hate having to upgrade over and over, and there's a danger they will just skip the upgrades and wait a while if they're too frequent.
Quote from Arantor on June 26th, 2011, 04:01 PM
2. It discourages people from upgrading. To me, an upgrade shouldn't just be about fixing problems, it should be an overall iteration on what was there before, so improvements (not necessarily new features, but improving existing ones) as well as fixing bugs.
Realistically, large upgrades are hard, especially for some deployments, and also dangerous just because of surface area.

Look at for example, Gentoo or CentOS or anyone.  They have slightly older versions of PHP/MySQL/OpenSSL/etc.  But these all have backported fixes.  Now, obviously, this is an annoyance... I'd rather everyone used the latest PHP.  But there are stability questions, and a whole slew of reasons why people prefer to use backported fixes.

A package manager isn't going to change this (one way or another), and a policy against the concept may stifle commercial adoption.
Quote from Arantor on June 26th, 2011, 04:01 PM
Most of the mod authors are not strong programmers, and invariably look for the easiest route to implement something, which means template edits in the first line of attack, source edits in the second, and almost never taking advantage of the resources actually in SMF to pull some of it off.
Sure.  My company also, for example, does customized Wordpress installs.  Generally, we write these as plugins and template changes, which solves the problem most of the time, sure.  But there have been times when we've done file edits, which certainly causes upgrade problems, and can even be hard to track since there's no management on top.  Too often, these installs get left un-upgraded because the client doesn't want to pay for the effort to upgrade them, even when it needs to be done.

Wordpress also does more to "freeze" the template interface, which is a whole separate conversation, and probably another factor to why complex themes don't generally exist.

And the default avatar - implementing this using TOX-G seems natural to me.  Assume for a moment:

Code: [Select]
Themes/default/basic.tox:
<tpl:template name="we:avatar" requires="url">
   <tpl:if test="!empty({$url})"><img src="{$url}" alt="" /></tpl:if>
</tpl:template>

Themes/cooltheme/basic.tox:
<tpl:template name="we:avatar" requires="url">
   <tpl:if test="!empty({$url})"><div class="avatar-box"><img src="{$url}" alt="" /><div></tpl:if>
</tpl:template>

Packages/defaultavatar/overlay.tox:
<tpl:alter match="we:avatar" position="before">
   <tpl:if test="empty({$url})">
      <tpl:set var="{$url}" value="{$settings.defaultavatar.url}" />
   </tpl:if>
</tpl:alter>

This seems natural to me.  It also means no problems like, say, accidentally setting someone's avatar to the default url when they edit their profile.  To avoid potential problems, this is probably how I would approach such a mod.

Making the right way easy is definitely a good thing.  Perhaps show a message when the mod contains file changes:
Quote
Warning: This package modifies core functionality of Wedge, and may need to be uninstalled prior to an upgrade.

When you upgrade, the package manager will automatically uninstall this package for you if it conflicts, and it may need to be reinstalled or even rewritten at that time.
It's good to warn people not to do things they probably don't want to do.  I still think there is an established use case for it, just as long as people are careful.
Quote from Arantor on June 26th, 2011, 04:01 PM
* File permissions, and making files writable to PHP, is one of the single most asked questions on the support boards -> can we make mods that don't need to make the core files writable?
I'm not sure this is a hard problem.  Yes, the package manager still has bugs in this area, and since writing it I've changed my mind on some things.  However, this goes back to another gripe I have... why isn't the webinstaller being pushed more?

Also, automatically restoring the permissions is something it should do, I thought it did.  If it doesn't, I just consider that a bug.
Quote from Arantor on June 26th, 2011, 04:01 PM
* Mods only working on certain versions, people asking whether mods will be updated -> does a mod expressly have to ask for a version, or can it attempt to determine if all the features it needs are available?
Yes, they do.  Look at extensions for Firefox, which don't do any "core edits."  Chrome has this problem less, but also the extensions can do a lot less.  And, for example, the latest "Page Speed" extension is broken in Chrome, and the latest Closure Inspector is broken in Firefox.  Both of these use plugin models.
Quote from Arantor on June 26th, 2011, 04:01 PM
* Mods searching for code and not finding it, because the original code has been modified (either by a later version, wherein even the comments get modified sometimes, or by another mod) -> can we make mods that either don't need to modify the files, or can better manage to sort themselves out without having to trip over each other?
Making it less likely is great.  Probably 80% of mods should never modify a file, and that could really help solve this problem.  I'd guess that the places where mods normally conflict is e.g. mod settings and such, places that are clearly hook fodder.
Quote from Arantor on June 26th, 2011, 04:01 PM
* Mods that need to modify templates -> why do they need to modify templates? Does it always have to be a template edit, or is it about the data the templates output? Can content be injected into a template in some other fashion?
Well, even in the worst case where they do modify a template, if things are more reused and base templates are inherited by themes and used, it's much less of a problem.

In general, I just feel like you are over-solving the problem.  Even if mods still just edited themes (without using TOX-G overlays, which although I made them as simple as possible, still take some thinking to understand), a system of inheritance and a larger set of templates would solve a lot of these problems alone.
Quote from Arantor on June 26th, 2011, 04:01 PM
making an installer script, but the more we talked about it, the more I felt comfortable abandoning file edits in the base.
Well, frankly, I see these installer scripts as way too complicated.  I think it's ironic that adding a core upgrade (to the upgrade SQL) seems to be easier and simpler than adding a table in a mod.
Quote from Arantor on June 26th, 2011, 04:01 PM
It does come up regularly enough. I'm not sure what you couldn't do with strategic insertion of hooks, it doesn't need to be insane.
Yes, but you're building a solution around a single problem, not the whole set of potential problems.  Given a specific mod, anyone could add the necessary hooks for it - but that's an unending problem.
Quote from Arantor on June 26th, 2011, 04:01 PM
It's not that hard to figure out. But premium sites can't use it because by definition everything in a package server has to be accessible by a simple GET and as far as I can tell, without any authentication handling.
If they were used more, there would be more feature requests, and this could be handled.
Quote from Arantor on June 26th, 2011, 04:01 PM
The thing most people seem to forget is that the bulk of mod authors aren't people just writing stuff to give away - they tend to write it for themselves and their site, then share.
I don't forget that, it's the same with everything.  Even the bugfix mods I wrote were really to manage them on my own site, and also share.  Not just to be a philanthropist.
Quote from Arantor on June 26th, 2011, 04:01 PM
Or better IMO, make the editor buttons configurable to the admin, so if they want to add them, they can. But yes, this could be achieved with hooks (even in SMF) and I don't think it is.
SMF's admin is confusing and overly complicated.  I'd rather see the complicated things (including custom BBC and editor buttons and such) be left as mods with just configurable hooks.  This is essentially what Wordpress does AFAICT and it's a win IMHO.
Quote from Arantor on June 26th, 2011, 04:01 PM
Well, I'd personally debate that it should be a core feature rather than a mod.
Why?  You want to add another checkbox somewhere for whether to show the page number in the title?  I'm sure some SEO people would go nuts about it, so it has to turn off.  I don't see it as having a huge number of people who want it either.
Quote from Arantor on June 26th, 2011, 04:01 PM
But I've seen even large-scale phpBB mods done, well, as lists of file editing, which says to me either there aren't hooks, or they're not really in use much.
And yet they are popular, and don't have some of the systemic problems SMF's mods have.  I think this points to file edits not necessarily being the culprit as you suspect, because if they were they'd affect other software equally.
Quote from Arantor on June 26th, 2011, 04:01 PM
That all said, I'm willing to bet that part of the problem is simply that most mods are contributed by people in their spare time, without any interest or desire in writing big and complex mods
Why does this not affect other software?  Are you proposing a different (more selfish) audience uses SMF than other forums?

I agree paid mods are a problem.  While SMF hasn't made those easy, I'm not sure how it has made them hard.  I think there's a lot to that problem as well.
Quote from Arantor on June 26th, 2011, 04:01 PM
I agree, to a point. The thing is, apart from the fact that it doesn't seem to have hurt MyBB or WordPress (and especially WordPress)
I think hooks are used very heavily in Wordpress.  Yet memory (and a cursory Google search) shows that patches and file edits are still used in their themes and plugins, often enough.  I know I've installed off-the-shelf themes for friends and had to do file edits manually.
Quote from Arantor on June 26th, 2011, 04:01 PM
I'm not convinced it will restrict to large or tiny mods.
I'm not saying it will, I'm just saying people will go to manual file edits.  I personally think (and have heard from many people) that SMF's managing these for you is still a good idea.
Quote from Arantor on June 26th, 2011, 04:01 PM
That's really what we have to do: just expanding hooks on its own won't be enough. We have to make everything else be more open to extension too, and upon doing that, almost anything should be possible.
Certainly.  That's a separate problem and a good problem to solve.
Quote from Nao/Gilles on June 26th, 2011, 09:03 PM
We aren't focusing on Stylings. I just offer them as an easy alternative for non modders who want to have different themes for their users without making it a hassle to maintain.
Okay.

-[Unknown]
Re: Unknown's thoughts on Wedge
« Reply #12, on June 26th, 2011, 11:47 PM »
Quote from Bloc on June 26th, 2011, 07:51 PM
but they will want more the things they can't imagine yet.
Absolutely.  I'm not satisfied with providing hooks only, because of this very reason.  Even if it means only one super cool not-yet-imagined theme or mod, I'd prefer to have the door wide open for it.
Quote from Bloc on June 26th, 2011, 07:51 PM
As I also mentioned on Blocweb, adding too many features in Wedge makes creating alternatives less desirable for others. Why create a gallery when theres one built-in?
Exactly, I think I said this about the calendar somewhere else.
Quote from Bloc on June 26th, 2011, 07:51 PM
Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
Ultimately, it needs to be done in baby steps or it will never happen.
Quote from Bloc on June 26th, 2011, 10:42 PM
In contrast, are there any mods that replace the moderating center in SMF2? In SMF11 there could have been more alternatives(was there more? I can't remember) but in SMF2 theres no reason to now. And that moderating center isn't a solution to all moderating needs..
Didn't 1.1 have some moderation center?  I never really used/liked/understood it to be fully honest.

The problem with features like that is they "bake" a specific idea into people's minds, such that it's harder to solve different ones.

For example, I use a callback-based HTTP system for some of my stuff.  This means, I do something like this:

Code: [Select]
$http->queue_get($url, $headers, $callback, $curried_params);

$http->queue_get($url, $headers, $callback, $curried_params);
$http->queue_get($url, $headers, $callback, $curried_params);
$http->queue_get($url, $headers, $callback, $curried_params);

$http->process();

The library itself multiplexes the sockets and executes the HTTP requests simultaneously.  It makes a number of requests, so these complete in a fraction of the time they would traditionally.

So, then, why is it that this model is so rare in PHP?  Well, since I hate curl, I'll blame it.  Since curl is an extension most people have in PHP, most people end up using it, not even the built in HTTP functionality of PHP.  Yes, it has a lot of features and is stable and built out well... no, it doesn't have a good security track-record in PHP nor a great PHP interface.

I'm the type of person who likes alternatives, and likes to write them.  Just because something exists doesn't mean it's the best.  But it's hard to approach something that has an integrated thing, and replace it.  For upgrade reasons, I would be more tempted to modify the existing feature, than to remove it and add my own.
Quote from Bloc on June 26th, 2011, 10:42 PM
if its part of what you set out to achieve then that won't matter lol.
Heh, don't apologize for having opinions.  Even if they aren't a right fit for Wedge's audience or goals, I think input from many is always a good thing.

-[Unknown]

Dragooon

  • I can code! Really!
  • polygon.com has to be one of the best sites I've seen recently.
  • Posts: 1,841
Re: Unknown's thoughts on Wedge
« Reply #13, on June 26th, 2011, 11:52 PM »
Quote from Bloc on June 26th, 2011, 10:42 PM
Quote from Dragooon on June 26th, 2011, 08:46 PM
Quote
To me it seems Wedge has already been laid out with that lesser possibilities for me as a designer, while SMF is still "full on"...although its focus on CSS-only themes takes away the focus on getting mods out of themes. But at least you CAN still change any template, luckily. I do remember Nao mentioned that it can be done in Wedge too, so its not all bad - but focusing on stylings sends a powerful signal out to any starting designer for Wedge.
Wedge's theme system is only beyond SMF's, it doesn't remove any of the previous possibilities but has enhanced capability for additional css variations.
Quote
But I also see WHY Nao/Arantor wants more features in - more powerful, central developing point etc. I think thats a slightly wrong turn though. Take Yourasoft, where a core was to replace SMF, with its forum as a module only(allowing others to also make other forum modules). It was from day one agreed that things should/could have alternatives.
Personally, I think it is a more positive turn. Not only does it ensure a system that is powerful and well integrated down to the core, it adds more capabilities for a small time modder to extend upon. It may discourage alternatives, but it doesn't necessarily prevent them. Instead, it helps to improve the existing system with multiple people pouring in.
Yes, its good..but honestly, why would anyone create a mod that does what Aeva does then? In contrast, are there any mods that replace the moderating center in SMF2? In SMF11 there could have been more alternatives(was there more? I can't remember) but in SMF2 theres no reason to now. And that moderating center isn't a solution to all moderating needs..

I am not saying to ALWAYS have alternatives..the quality will maybe be worse sometimes, but with Aeva as built-in rather than a plugin, you will not see any evovlement in that area other than what you do yourself. It depends on how you look at it if thats a good thing or not.
Currently there are only 2 gallery mods for SMF, Aeva and SG(3 of you count SGL and SGP separately), and I created SMG(Base of Aeva) after SGP had been out for over 2 years(And it had dominated that time). Same's the case with TinyPortal, it had been out for a long time before an alternative game, simply because it dominated for a long time. Now there are 5 portal, which do the same thing in more or less the same way. So in all honestly, having a feature in core won't make that much of a difference provided there is someone who is willing to do that kind of effort to match up to it. This is emphasized by the fact that Nao spent 2 weeks straight on SGP before I released SMG, only because he didn't want to create one from scratch and had SGP as a base . Instead, most will try and improve what is in the core rather than making an alternative to it. This way a new kind of variety will be created. Plus we always got integration to 3rd party systems.

Arantor

  • As powerful as possible, as complex as necessary.
  • Posts: 14,278
Re: Unknown's thoughts on Wedge
« Reply #14, on June 26th, 2011, 11:59 PM »
Unfortunately right this moment I don't have time to reply to everything but the stuff I see as really important I'll deal with right now and tackle everything else shortly.
Quote
Yes, they do.  Look at extensions for Firefox, which don't do any "core edits."  Chrome has this problem less, but also the extensions can do a lot less.  And, for example, the latest "Page Speed" extension is broken in Chrome, and the latest Closure Inspector is broken in Firefox.  Both of these use plugin models.
And that's because they still depend on version checking. My proposed method explicitly does NOT check for Wedge version.
Quote
It's good to warn people not to do things they probably don't want to do.  I still think there is an established use case for it, just as long as people are careful.
That's one of my points: I don't see people being careful. I see it as enabling the shortest route to a problem, which leads to all the things I mentioned before.
Quote
I'm not saying it will, I'm just saying people will go to manual file edits.  I personally think (and have heard from many people) that SMF's managing these for you is still a good idea.
Following on from that: I'm not against file edits per se, for all the reasons you've mentioned. I just don't want to leave them in because people will continue using practices they learned in SMF rather than learning new habits, like using hooks where there are hooks available for things.
Quote
Why does this not affect other software?  Are you proposing a different (more selfish) audience uses SMF than other forums?
It probably does, I haven't spent any time in their ecosystems. But given the mods submitted, the relative skill level of the coders and so on, the majority are certainly not contributed by veteran coders.