Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Arantor
6031
The Pub / Re: Spell checker
« on October 9th, 2011, 06:42 PM »
Therein lies the issue. If you bundle a plugin in the core, why is it not actually core? Most users won't care that the two things are separate.
On the other hand, if you have these things as plugins, it's not so obvious about enabling/disabling them, which is the one reason I'm so set on removing Core Features. Go through the SMF 2 support board and see how many people ask about post moderation. I appreciate there's a reason it's disabled by default[1] but the simple fact that it's completely non-obvious that you have to go there erodes most of the value of splitting things off.
In our case, yes, we could put the calendar and memberlist and so on into the Plugins/ folder in the trunk and have them developed there (and thus auto bundled) but you'd have to go to the Plugins page to enable them, which is as counter-intuitive as going to the Core Features page, in fact possibly more so.
Which means I'd have to extend the plugin system to provide some way of directly adding items to the admin menu so they can be activated (much as the calendar currently can be)... doesn't seem that encouraging to me.
I'm not against the idea in principle, because I'm all too aware of the benefits of segregating the code up into bundles that are self contained, but I'm concerned at the usability for end users.
On the other hand, if you have these things as plugins, it's not so obvious about enabling/disabling them, which is the one reason I'm so set on removing Core Features. Go through the SMF 2 support board and see how many people ask about post moderation. I appreciate there's a reason it's disabled by default[1] but the simple fact that it's completely non-obvious that you have to go there erodes most of the value of splitting things off.
In our case, yes, we could put the calendar and memberlist and so on into the Plugins/ folder in the trunk and have them developed there (and thus auto bundled) but you'd have to go to the Plugins page to enable them, which is as counter-intuitive as going to the Core Features page, in fact possibly more so.
Which means I'd have to extend the plugin system to provide some way of directly adding items to the admin menu so they can be activated (much as the calendar currently can be)... doesn't seem that encouraging to me.
I'm not against the idea in principle, because I'm all too aware of the benefits of segregating the code up into bundles that are self contained, but I'm concerned at the usability for end users.
| 1. | Though I still think that's possible to overcome. |
6032
Features / Re: Scheduled tasks interface
« on October 9th, 2011, 06:32 PM »
That's the thing: I'm just not seeing the point. Way back when I put this topic out there, the plugin manager wasn't even the merest glimmer of imagination in my brain, I certainly hadn't fleshed out the notion of being able to add a scheduled task from a plugin with three lines of XML.
The whole point about the scheduled tasks stuff is that it's designed to be run under a minimalist setup, so that having a UI for it seems counter-productive.
The whole point about the scheduled tasks stuff is that it's designed to be run under a minimalist setup, so that having a UI for it seems counter-productive.
6033
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 9th, 2011, 06:29 PM »
You're allowed to be tired. It's been a long road this last year, and I'm sorry I wasn't able to spend quite as much time on the dev trail as I'd have liked. But I'm able to put the time into it right now, which means likely a flurry of commits as I make the changes I want to make, and then the commits to fix mistakes I make... *whistle*
The other thing is that when we started out, we had a lot of motivation fuelled by anger, and that's tempered a fair bit as they sort of got their act together, but moreso because we've put a lot of it behind us so we're able to see things more objectively now than a year ago.
That's partly why I'm pushing plugins the way I am, it enables me to spend a few hours on something and be able to call it close enough to 'done' to not worry about it. Sure, I'll go back to my plugins in a week or a month or whatever and do more work - but it's something bitesized that doesn't drain my energy too much.
The other thing is that when we started out, we had a lot of motivation fuelled by anger, and that's tempered a fair bit as they sort of got their act together, but moreso because we've put a lot of it behind us so we're able to see things more objectively now than a year ago.
That's partly why I'm pushing plugins the way I am, it enables me to spend a few hours on something and be able to call it close enough to 'done' to not worry about it. Sure, I'll go back to my plugins in a week or a month or whatever and do more work - but it's something bitesized that doesn't drain my energy too much.
6034
Features / Re: Notify Admin when a new member joins
« on October 9th, 2011, 05:55 PM »
OK, so next thought.
Should this be open to any forum member, or limited to - say - those who are admins and global moderators?
If the latter (which is what I'm guessing), I'm tempted to just make it a list of names with checkboxes...
Should this be open to any forum member, or limited to - say - those who are admins and global moderators?
If the latter (which is what I'm guessing), I'm tempted to just make it a list of names with checkboxes...
6035
The Pub / Re: Spell checker
« on October 9th, 2011, 04:18 PM »
*nods* However it ends up being done, it should be done thoroughly for things like that.
6036
The Pub / Re: Spell checker
« on October 9th, 2011, 04:02 PM »I feel that if a plugin is going to be bundled it may as well be a core feature since it's shipped with the software anyway (this was my stance against SD's Frontpage being bundled).
On the other, it does add the usability issue - and therein lies what you're getting at. If it is bundled, it's effectively saying 'I should be core'. But it does also allow for disabling and removing something you're not going to use and to re-add it back later.
Yes, I doubt most sites change the default settings, but I can fully imagine sites that would want those things gone, and I know I've been asked about both in the past (and incidentally, both PM and memberlist are the two areas removed by SimpleDesk's standalone mode, funny)
But it's that distinction that prompts me to keep them in, even if they could be split off without too much headache. Just because I can doesn't necessarily mean that I should.
Posted: October 9th, 2011, 03:50 PM
Interesting to note how my own interpretation of things changes over time.
Specifically: http://wedge.org/pub/feats/6469/how-about-pms-being-listed-in-core-features/
That's probably the clearest case of an 'I want to be a plugin' example in this case. But certainly being disable-able centrally.
6037
Features / Re: Scheduled tasks interface
« on October 9th, 2011, 04:00 PM »
OK, dredging this one up.
I'm no longer convinced that it's actually necessary to revisit the scheduled tasks interface. See, it's all well and good being able to add a task but unless you've got some code to run it's not really worth it.
And with the plugin setup it's much easier to actually declare a scheduled task now (and if you're up to writing the code for a scheduled task to run, you're certainly capable of creating a minimalist plugin; there's a direct interface for receiving scheduled tasks in the XML structure of plugins, by design)
I'm no longer convinced that it's actually necessary to revisit the scheduled tasks interface. See, it's all well and good being able to add a task but unless you've got some code to run it's not really worth it.
And with the plugin setup it's much easier to actually declare a scheduled task now (and if you're up to writing the code for a scheduled task to run, you're certainly capable of creating a minimalist plugin; there's a direct interface for receiving scheduled tasks in the XML structure of plugins, by design)
6038
Plugins / Re: Personal plugin showcase (yes, I'm an attention grabbing git)
« on October 9th, 2011, 03:55 PM »
I've done some bits, and will likely tackle some more today. I'm in a funny mood today, can't seem to settle and be in the 'coding place'.
Btw, once I've got a few more plugin-y type things together, I'll do another blog post. It's been almost a month since our last blog post, so probably time to post something else - and we have screenshots we can use :)
Posted: October 9th, 2011, 03:37 PM
Btw, once I've got a few more plugin-y type things together, I'll do another blog post. It's been almost a month since our last blog post, so probably time to post something else - and we have screenshots we can use :)
6039
The Pub / Re: Spell checker
« on October 9th, 2011, 03:37 PM »
I thought about that, and that was in part why I moved the plugins entry to the end of the list so that any plugins could create their own items in there for that reason (and not end up pushing stuff way way down the list)
The mechanics of the plugin manager certainly don't prevent it, but I think having many items in the menu might be a bit fragile. Even with the rewrite of the menu code, I'm still wary of putting more than 10 items in any given menu area.[1]
In fact, that's why I haven't put in a specific interface for plugins to hook into to declare new items automatically, because I'm not convinced plugins should have to restrict themselves to a single top level item somewhere. Some plugins need an entire menu (like WedgeDesk), some will want configuration items embedded into the existing architecture (like reCAPTCHA), and I don't want to break that.
Plus, one of the perks of the list of plugins as it stands is that it tries to determine is a plugin is enable-able or not. I wouldn't want to apply that logic to be run on the front page every time.
The mechanics of the plugin manager certainly don't prevent it, but I think having many items in the menu might be a bit fragile. Even with the rewrite of the menu code, I'm still wary of putting more than 10 items in any given menu area.[1]
In fact, that's why I haven't put in a specific interface for plugins to hook into to declare new items automatically, because I'm not convinced plugins should have to restrict themselves to a single top level item somewhere. Some plugins need an entire menu (like WedgeDesk), some will want configuration items embedded into the existing architecture (like reCAPTCHA), and I don't want to break that.
Plus, one of the perks of the list of plugins as it stands is that it tries to determine is a plugin is enable-able or not. I wouldn't want to apply that logic to be run on the front page every time.
| 1. | There's no reason for it on a technical level. In SMF, there was a good reason not to: the menu bg didn't go beyond 10 items. But in Wedge, the only reason I'm wary of it is usability. More than 10 items in a list is mentally harder to process unless they're grouped in some fashion. |
6040
The Pub / Re: Spell checker
« on October 9th, 2011, 03:17 PM »
*nods* I still look back at my own experience with PunBB on this one; polls to me are a pretty core feature.
What it comes down to really is inertia, how much people would be willing to put up with before considering different software.
What it comes down to really is inertia, how much people would be willing to put up with before considering different software.
6041
The Pub / Re: Spell checker
« on October 9th, 2011, 03:02 PM »
That's my gut instinct, as much as I can see the benefits to pushing some of those into plugins, the calendar especially.
6042
Features / Re: New revs - Public comments
« on October 9th, 2011, 02:28 PM »As long as it's decoded back into $txt[$error] on the other side of the log viewing code...
So, if a user tries to read a topic they can't access, the usual "Reading <topic>" will appear in Who's Online, with a little warning icon whose tooltip is the error. It was the cleanest way I could think of to solve the problem of "hey, I think my forum is broken, users can see topics in private boards" because when it looks up the list, it only looks at what the user is requesting, not whether the user has permission.
I don't really have a problem with merging them, provided that we don't break anything else.
I don't know either but I'm no specialist.
Really?
Nowhere...
But I just couldn't find...
6043
The Pub / Re: Spell checker
« on October 9th, 2011, 02:18 PM »
The idea is certainly that the modularisation of the plugin system should make it possible to do that; there is absolutely no reason why it shouldn't be achievable.
However, I do see a practical constraint: usability. Bundling plugins is doable, auto-activating them slightly less so, but it is possible - right up until the user wants to configure them or whatever - it means that they have to go to places they wouldn't normally associate with these things in order to alter them.
Also note that the statistics page could be unbundled, but I'm not sure the statistics gathering could be, unless it became a stock bundled plugin, enabled by default.
Ironically, though, our biggest plugin candidate is probably the one plugin I can't see us removing: AeMe, as the intention is to have it handle attachments and avatars to replace the existing core for that.
I'm sort of on the fence as far as moving things like mlist and PMs into plugins. I'd appreciate more feedback on it from what people want.
For example, how often is the member list disabled for non-admins? (who can use the admin panel version anyway)
Mind you, taking a look at PunBB's extension list, they have so much not in the core it's unreal. Having a CAPTCHA on registration, attachments and more are not core features :/
However, I do see a practical constraint: usability. Bundling plugins is doable, auto-activating them slightly less so, but it is possible - right up until the user wants to configure them or whatever - it means that they have to go to places they wouldn't normally associate with these things in order to alter them.
Also note that the statistics page could be unbundled, but I'm not sure the statistics gathering could be, unless it became a stock bundled plugin, enabled by default.
Ironically, though, our biggest plugin candidate is probably the one plugin I can't see us removing: AeMe, as the intention is to have it handle attachments and avatars to replace the existing core for that.
I'm sort of on the fence as far as moving things like mlist and PMs into plugins. I'd appreciate more feedback on it from what people want.
For example, how often is the member list disabled for non-admins? (who can use the admin panel version anyway)
Posted: October 9th, 2011, 02:12 PM
Mind you, taking a look at PunBB's extension list, they have so much not in the core it's unreal. Having a CAPTCHA on registration, attachments and more are not core features :/
6044
Features / Re: New revs - Public comments
« on October 9th, 2011, 02:06 PM »
I used a mix of my own memory and Google Translate when my memory failed me. I knew it probably wasn't perfect but I figured I'd give it a shot, and while I haven't had time to check the fixed translation, I'm willing to bet that not having 'here' in a separate string (for example) allows for better translation.
No, it shouldn't be $txt[$error] passed to the update counter, it should be the $error on its own - the second parameter indicates where it came from, false for fatal_error, true for fatal_lang_error, because it deliberately doesn't stuff the entire message into the online table if it doesn't have to.
The removal of the %p test in Subs... At the time I concluded it was redundant; the only language that I'm aware of that uses AM/PM in a 12-hour context is English, and I don't know any other language that prefers a 12 hour context over a 24 hour one. I can reinstate it but frankly I'd rather push English to 24 hour before I supported 12 hour more...
Where else is $txt['with'] used? If it's not used anywhere, remove it. Also check for merge_ on its own, strings get compounded a lot in the code.
No, it shouldn't be $txt[$error] passed to the update counter, it should be the $error on its own - the second parameter indicates where it came from, false for fatal_error, true for fatal_lang_error, because it deliberately doesn't stuff the entire message into the online table if it doesn't have to.
The removal of the %p test in Subs... At the time I concluded it was redundant; the only language that I'm aware of that uses AM/PM in a 12-hour context is English, and I don't know any other language that prefers a 12 hour context over a 24 hour one. I can reinstate it but frankly I'd rather push English to 24 hour before I supported 12 hour more...
Where else is $txt['with'] used? If it's not used anywhere, remove it. Also check for merge_ on its own, strings get compounded a lot in the code.
6045
The Pub / Re: Spell checker
« on October 9th, 2011, 12:41 PM »
Interesting approach, I hadn't actually considered going quite so far in doing things, especially as way back in the mists of time, my first forum was a PunBB one, and I moved to SMF 5 years ago precisely because PunBB didn't have polls built in and back then I wasn't too enthusiastic about adding features as plugins/extensions.
I have come a long way! :lol:
Calendar I'm cool with. Polls... not so much for the above reason but I can certainly see the logic. PMs I'm actually inclined to consider a core feature but there isn't much reason why it couldn't be moved into being a plugin in practical terms.
I guess it depends how we consider Wedge to be: more modular and extensible or more fully featured up front?
I have come a long way! :lol:
Calendar I'm cool with. Polls... not so much for the above reason but I can certainly see the logic. PMs I'm actually inclined to consider a core feature but there isn't much reason why it couldn't be moved into being a plugin in practical terms.
I guess it depends how we consider Wedge to be: more modular and extensible or more fully featured up front?