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
6316
Plugins / Re: Converting WedgeDesk
« on September 23rd, 2011, 03:59 PM »
*nods*

There's a whole bunch of stuff I'm going to be picking up in WD, like differentiating between closed and resolved, and stuff like that - and making it a ton more flexible in other ways too, because I'm hardcore like that. (The notion of a unified helpdesk and project/bug tracker seems appealing to me, and if I can unify it into the system I normally use for authentication and so on, so much the better.)

Oh, you should see the plans I have for the future, not just WD but for the Wedge add-ons I plan to write (for the stuff that I think is desirable/useful but too big and expansive to be in core), it's going to be a glorious ride. :D
6317
Plugins / Re: Converting WedgeDesk
« on September 23rd, 2011, 03:41 PM »
In other news, looking like Mantis familiar yet? :P[1]
 1. And no, I very definitely did not steal the colours Nao came up with on tracker.wedge.org. Very definitely.
6318
Plugins / Re: Converting WedgeDesk
« on September 23rd, 2011, 02:28 PM »
Yeah, that's the message I was getting from RT is that it's pretty but it didn't look like it could cope with something more complex.

Meanwhile, WD occupies a fun place because when I go live with wedgedesk.com, I'm going to be using it for both helpdesk and project tracker, so I'm intentionally supporting both styles (which is why the Mantis-esque layout is being introduced, amongst other things)
6319
The Pub / Re: Copyrights
« on September 23rd, 2011, 02:27 PM »
Quote
are you still of the opinion that you prefer domain.com/profile/User/ to domain.com/~User/...? I've reworked the code to use /profile/ instead (I mourned the idea long enough that it doesn't particularly bother me now), I can commit it if you want.
Yes, I am. It's not like we see ~name URLs much these days, so it's mostly the old-timers like us who'll remember it. Go for it :)
Quote
"Hey guys, you used $modSettings in your code! You should add a copyright!"
It really wouldn't phase me to rename $modSettings, $settings and $options to something more meaningful actually.
Quote
"Hacking attempt" -- agreed. any suggestion to replace this? "You can not run this PHP file directly"? "You must run this action through index.php"? "If I'm a chicken, then you're my egg"?
'You cannot run this PHP file directly.' works for me, since legitimate users shouldn't anyway... Buried in at least one of the WD files is 'If only you could draw like a drunken monkey...' as the equivalent text, interestingly enough.

Alternatively, a few more creative choices:
I am the sin, and the fire, and the darkness!
It's been a long time since anyone's said no to you, isn't it?
Spoilers!
It's what's in the dark. It's what's always in the dark.
We've got to go. This reality is sealing itself off, forever.

:lol:
Quote
Weren't you the one who removed it to begin with?
Yes, because I originally didn't suspect they'd be quite as hardline as they seem to be about it.
Quote
Yeah, a few more files.
We could even split some files in two just for the pleasure of not mentioning them in the new one...
Bwhahha, sounds like a plan :P
Quote
@copyright based on portions © 2011 Simple Machines, rewritten by Wedgeward © 2010-2011, wedge.org
@copyright © 2010-2011 Wedgeward, wedge.org (uses portions © 2011 Simple Machines)

Oh, and where do we define what Wedgeward is...? Only in the license file?
I'd suggest the latter line, it doesn't put as much emphasis on SM as the first one does, IMO.

Same argument, where is Simple Machines defined? There's a link to wedge.org, and it's available there, so I'd say that's fine as is.
Quote
Well, I guess it all depends on how it unfolds eventually.
I doubt it'll change any time soon. There's still going to be hate (even as recently as a few weeks ago, a certain person was calling us assholes and telling the world that Aeva's badly written, until Motoko told him that SAVE was badly written, though in a manner that implied he thought Aeva was as well)

The only way the hate is going to change is if we make another move towards being open - even then I doubt the true hardcore fanbois will ever change their mind. But I'm not that bothered to be honest, I thought it was a nice touch of respect for their contributions to leave it in, much as I have with WedgeDesk's credits, but I have no plans about removing the credits there even though I consider WD pretty much a hostile fork.[1]
 1. The 'hostility' such as it is, is totally on my side. It's not even actually hostile, it's just simply not a friendly fork contributing code back to SD, even though I am aware that some of the code I posted in private to help out has since been reposted publicly. I don't really mind because I doubt anyone else was going to step up to the plate to achieve what needed to be done, but it'll be solved and solved better in WD.
6320
Plugins / Re: Converting WedgeDesk
« on September 23rd, 2011, 01:41 PM »
RT is something I was made aware of but I really can't be arsed going through the steps to actually install it to play with, seeing how it uses Perl and I don't have Perl handy and don't really want to make yet another virtual machine to work on.

Mantis has a lot of things about it that I dislike and a few things I really like that may well migrate to WD in the future.
6321
Features / Re: New revs - Public comments
« on September 23rd, 2011, 01:37 PM »
I'm cool with the template changes :)
Quote
I'd be tempted, though, to split these into more functions, like 'replaceBlock' and 'addBlock'... Dunno which would be best, really (especially given the number of choices I offer. One function for each...?!)
I'd avoid making too many functions, especially if they're fairly similar or related. Trust your instincts on this one.
Quote
Or having functions outside the object, and the object only manipulated through these functions like loadBlock()...?
No, if you have an object whose job it is to handle the template skeleton, not only is it the holder of the data, but it's also responsible for changing that data. In any case, if it's to be tamper-proof except for through the defined methods, the methods have to be part of the object because you'd make the list itself a private variable - which by definition can only be manipulated inside the object's own methods, and is never made directly available outside of it.
Quote
Yeah, true dat!
It would make sense to actually display the faulty query etc to them...
At least then there would be a useful start to debugging...
Quote
I believe we should store somewhere the number of language files available. If it's > 1 we call getLanguages() either way. We'll only use $modSettings['userLanguage'] when in the index template, just before showing the flags themselves.
You know, we could just ship with both English and French installed by default so it's always > 1 :whistle:
Quote
It's probably my greatest failure of these last few months. Have you noticed how I keep postponing them...?
I had noticed, but I'm not in the slightest surprised. It's a massive undertaking at the best of times, and it has so many knock-on effects that it will inspire fear and dread in anyone.
Quote
I keep thinking of situations where the current attachment and avatar systems make more sense than Aeva's
There aren't that many situations, and frankly I think they're avoidable too.

The main ones that I envisage are where you end up with what amounts to a single album that contains all the attachments, but that access rights to that album are inconsistent with how an album usually functions. That, and separating viewing a thumbnail from viewing the main file (it's a fairly common request because SMF says either you can see it or you can't, no in-between ground)
Quote
*or* may require users to change the way they see things
As you reminded me yesterday, http://yarr.me/cache/8a07b66f80a1982895b8acf157fe1002.jpg

I have no problem with changing how users see things, provided that where we go to is a logical, meaningful place. To me, sifting out the code so that we have one path for accessing attachments/avatars/gallery items seems like a logical place to go - and we get the benefits of integrating Zoomedia cleanly :)
Quote
I love having a drop shadow on my avatar, and want it on every forum I go to, but I just don't want a drop shadow when I'm using a transparent avatar!
Nothing wrong with having ambition. Maybe that is a little unbalanced in terms of work vs reward (though far less so than building a wall just to put a hook on it for a coat), but I think it's a meaningful one because right now we have two distinct paths to serving files and so on, even though the operations are virtually identical, and we should fix that.

Really: what's the difference between what MGalleryItem does and what Dlattach does? They still look up where a file is, whether the user can see it or not, and ultimately serve the file.
Quote
Yeah, and more than that... Topic level. See what I mean. (If we implement topic privacy. Another of my recent failures.)
Again, I don't really see it as a failure, no more so than my not having reimplemented permissions yet. It's just another thing to do that has massive system-wide consequences and can easily turn into a tour-de-force of bug hunting.
Quote
I'm not sure I understand.
OK, best thing to do is take a look at the code in the modified Download() function in Display.php on this site (or, failing that, a fresh 2.0 final install with SD 2.0 installed).

Firstly, it checks for 'avatar' in the URL, and if so, it queries for the avatar's details (filename etc.). If not, SD's injected code looks for 'ticket' in the URL, and if so, it tries to query for the details *there*. Failing that, it just looks for the normal route (attach id + topic id)

Note that it doesn't *fetch* the information at this point, merely queries for it, and then passes the query result to the fetch code, so regardless of the query actually run, it knows that no rows means the attachment can't be found or seen (either way, it neither knows nor cares which), otherwise it serves the file it has.

SD added its own handler in there, and I can envisage something similar in the attachment code, whatever form it's in, to have a hook, and see if anything attached to the hook will validate the requested file, and if so, prepare to serve it.
Quote
Oh, and if we have board-level permissions, then I suppose we could (should?!) modify Aeva to use boards and topics instead of albums and items. Not sure about that yet, though... It basically means implementing the floating topic stuff.
Yup. So many inter-related parts, it's so hard to judge where to start.
6322
Plugins / Re: Converting WedgeDesk
« on September 23rd, 2011, 12:32 PM »
So it looks nothing at all like Mantis :whistle:

Maybe if I put the colouring in...
6323
The Pub / Re: Copyrights
« on September 23rd, 2011, 12:31 PM »
Quote
Including files that are 100% ours, like the addon code or my CSS preparser?
No, any files that are 100% ours can forgo that line. (You know, we really should change that warning to something other than 'Hacking attempt', then we solve that problem too.)
Quote
Anyway, it can be read in two ways. The REDISTRIBUTION must retain the copyright stuff. It doesn't say EVERY file should have it, does it...?
Seriously. Their LICENSE file says it must be kept. Then we keep the license file. As for the rest... Well, the only thing common to both the license file and all remaining files is the copyright line indeed. So it can be argued that they want it to be left. I personally don't think it's worth worrying about... It's not like we're hiding that it's SMF to begin with.
I'd tend to ask them.
Guys, either we keep your license file and your copyright line (only that) in all files you created. Or, we only keep your license file, but we acknowledge SMF in the credits area with a link to its site. Your choice.
It's a matter of debate, but as far as I'm concerned, provided that we retain some semblance of mentioning their copyright per file, and the licence file states that the code is based off SMF's, we have fulfilled our criteria because it's keeping the terms of their licence intact and in the distribution.

Any code that's not theirs or derived from theirs can safely exclude mentioning them, which does indeed cover pretty much all of Subs-Cache, all of ManageAddons, media/* from what I remember of it and probably more besides.
Quote
That makes for a long copyright line... And the SM name appears prominently (at the end).
Too bad phpDoc doesn't "support" a @contributor(s) line, but why wouldn't we simply add such a line...?

@copyright © 2010-2011 Wedgeward, wedge.org
@author Wedgeward (René-Gilles Deberdt, Peter Spicer)
@contributor contains portions © 2011 Simple Machines
It's only an issue if someone then actually proceeds to build off phpDoc doc files off it, though I guess we might do that in the future. The argument is that if they're contributing, they're validly part of the copyright normally anyway. I also think I'd rather have one long-ish line than two for the purposes of noting copyright.
Quote
Dunno if it's specified, but at least it's implied.
For the avoidance of doubt it should be specified.
Quote
If we do that, then we don't really need to keep their names in the readable credits... I want to keep occurrences of the name "SMF" to a minimum.
We don't *have* to keep their names in the credits at all, there is absolutely no requirement to do so, given that as far as I'm concerned we would have complied with the licence by mentioning it via their copyright and the licence file.

I just think it's kind of nice to leave it though.
6324
Plugins / Re: Converting WedgeDesk
« on September 23rd, 2011, 03:00 AM »
In other news, I couldn't get my brain in gear to do some of the add-on manager stuff (been ill the last few days) so instead I fired up WedgeDesk and started adding one of the new layouts that it'll contain. (There are plans for four layouts for tickets. This is the second one.)

Look familiar, much? :lol:
6325
Features / Re: New revs - Public comments
« on September 23rd, 2011, 12:57 AM »
Quote
The fact that $where defaults to 'replace' when $target == 'default and defaults to 'add' everywhere else...
Seriously, it's fine. It might sound odd but it actually works fairly well in practice (now that WedgeDesk does it)
Quote
Although I'm totally pro-objectifying (?) stuff, including mine, I wouldn't know where to start (i.e. I can maintain an object but convert something to an object is something I can't do with confidence), I'm also not sure whether it's actually worth the hassle... I mean, if a mod removes 'default', their author will notice soon enough...
Whether it being worth the hassle is a good question. But it would certainly prevent random tampering with the arrays directly, and it becomes more semantic because instead of having generic (but nicely named) functions, you have an object to which all the functions physically belong.
Quote
I'd tend to say that admins are in the same crap as users here -- it's really the themer we should be talking to...
This is one of the issues I have with SMF's error messages. In the event of a database error, it can quite easily say something to the effect of "There has been a database error, please refer to the administrator." Which is fine - until it displays that message, as is, to an administrator when they're logged (and after determination of permissions has occurred)
Quote
No, that's not what I was saying... If a board has a default language, different than the forum's, *and* the admin disabled the ability to change languages for users, i.e. $modSettings['userLanguages'] or whatever is false, then getLanguages() is not called... And my test code isn't, either.
Hmm, not sure how to proceed on that one.
Quote
I haven't written it down, but XDebug basically crashed saying "delimiter is empty", IIRC.
Yup, it's complaining that $addonsdir doesn't make sense to it. I'll fix it sometime, have other things going on, like add-on related stuff.

Also, in add-on related news, WedgeDesk is now capable of being installed (and running) cleanly from the add-on manager. The only thing it can't handle right now is attachments, and that's only because it's expecting to use the old attachment handling code which I haven't removed yet.

On that note, actually... I was thinking about how to handle attachment access for things like WedgeDesk that have their own authentication needs and that have different needs to the norm. Galleries, by definition, are accessed at gallery level, but we need to change that to being determined at board level for attachment gallery items. I'm not sure how we'd do *that*, but the solution for handling attachments generally when it's an external source seems fairly clear: have a hook that attempts to make the query that Dlattach.php normally would (or MGalleryItem.php, whatever query would normally be run to identify a file and validate the user can access it), and the hooked functions should return the necessary information, or false - that way, systems can deal with it as necessary.
6326
Features / Re: New revs - Public comments
« on September 23rd, 2011, 12:40 AM »
Re r1024: Um, $addon_dir shouldn't ever be empty because it should be set earlier in the file (lines 37-8)... what exactly was the error you were getting?
6327
Off-topic / Re: I am looking for a favour
« on September 22nd, 2011, 12:36 AM »
Opera 11.51 on Windows doesn't do it for me, I even went to the jQuery website and the demo site and still could not reproduce this behaviour.
6328
Other software / Re: More thoughts on SMF 2.1
« on September 21st, 2011, 06:11 PM »
That is very, very true. I await with anticipation to see how we both turn out going forwards.
6329
Plugins / Re: Add-on Manager: Mechanics
« on September 21st, 2011, 03:06 PM »
That would work as a temporary measure, but long term, modders who want to add columns to core tables should be doing it on a case by case basis.

The long term reason is what happens when there is cleanup done in the remove-clean scenario, whereupon it will remove tables and columns and so on.
6330
Plugins / Re: Add-on Manager: Mechanics
« on September 21st, 2011, 02:59 PM »
It's only because it's not yet written... as stated it will be added.

Meantime, add it manually in a PHP script, loaded through <enable> in the <scripts> inside <database>. I forgot to mention it above, but any of the enable/disable/remove/remove-clean scripts should really do a test for the constant WEDGE_ADDON being declared and exiting promptly if not. (It's only defined in the add-on manager.)

Failing that, they can use SSI if they really want but it's not best-practice IMO.