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.
Topics - Arantor
136
Bug reports / Double space bug in thoughts + others
« on October 4th, 2012, 06:06 PM »
As mentioned in the thoughts recently, documenting this bug so it can be fixed at some point.
preparsecode converts a double space to a single space followed by an nbsp entity, so that the usual collapsing of spaces does not occur. Trouble is, that extra entity is being escaped at some point between being saved and redisplayed.
Now, the two branches of the front page in SVN (the Home and Welcome templates, of which Welcome is the default) do not exhibit this bug.
They do have other bugs, however, where the AJAX return is inserted without values being injected into the return, plus neither of them is as functional as the master template is here.
There also really should be some kind of entry box on the front page for thoughts - in case folks do what I do and have the sidebar at the bottom, and it would also mean that the thoughts subtemplate should not be removed from the front page if the users have some ability to post.
(Also on that note: thoughts need some permissions adding!)
preparsecode converts a double space to a single space followed by an nbsp entity, so that the usual collapsing of spaces does not occur. Trouble is, that extra entity is being escaped at some point between being saved and redisplayed.
Now, the two branches of the front page in SVN (the Home and Welcome templates, of which Welcome is the default) do not exhibit this bug.
They do have other bugs, however, where the AJAX return is inserted without values being injected into the return, plus neither of them is as functional as the master template is here.
There also really should be some kind of entry box on the front page for thoughts - in case folks do what I do and have the sidebar at the bottom, and it would also mean that the thoughts subtemplate should not be removed from the front page if the users have some ability to post.
(Also on that note: thoughts need some permissions adding!)
137
Features / Categories as boards
« on October 3rd, 2012, 03:58 AM »
This is a slightly odd proposal but here me out.
People often want to make sub-categories. While you can certainly use sub-boards for organisation, categories do offer a clearer method of organisation - you don't just get to separate boards into a hierarchy, you can create a sideways hierarchy or sorts too.
And it occurred to me: if you create a category as a type of board, you get to create sub-categories, apply permissions, and probably even simplify the code should you want to do so.
Thoughts?
People often want to make sub-categories. While you can certainly use sub-boards for organisation, categories do offer a clearer method of organisation - you don't just get to separate boards into a hierarchy, you can create a sideways hierarchy or sorts too.
And it occurred to me: if you create a category as a type of board, you get to create sub-categories, apply permissions, and probably even simplify the code should you want to do so.
Thoughts?
138
Features / Hellbanning, aka global ignore
« on October 3rd, 2012, 02:58 AM »
I've been thinking about this for some time. As part of my extensions into the warning/banning system deal, I've been considering adding this in as a last resort.
Hellbanning, or global ignore, is an option whereby all topics and posts by a user are invisible to everyone except themselves. The idea is that they can post freely without realising that no-one else can see their nonsense.
There are some interesting asides to it:
1. Performance is likely negligibly affected, if implemented in the core. As a plugin it's a bit different but probably not that significant. (It's just way cleaner if I make it part of the core)
2. If the user was once a meaningful participant, it could be awkward to hide all the posts and topics as if they never happened, meaning you almost have to consider making it a filter applied at the post level to block a user's contributions after a given point (which *does* bring in all kinds of performance considerations)
3. There are potential issues with hiding posts - you never actively tell the user that they're being punished, but that's part of the point. Never telling them means they don't know, and beat themselves against a wall until they leave. It also means they never have a way to defend themselves or represent themselves.
Basically, I want to give people tools to be able to manage their communities. I want them to be able to deal with troublemakers and have whatever tools will be able to do that effectively. This is why I want to make the warning system more granular, so that instead of very broad levels of punishment (watched/moderated/post banned), you can have punishments that suit every level of troublemaker, right up from inappropriate signatures and avatars (temporary/permanent removal of specific privileges) through to inappropriate content (various tools that I don't want to mention yet, heh[nb]I have some... interesting... ideas that I don't want to spoil yet but that will really help with dealing with troublemakers IMO), and generally inappropriate behaviour (moderation, inability to login/browse, i.e. bans)
The other matters, removal of privileges etc. are fairly subtle but ultimately quite 'safe' punitive measures - a user who is subject to them knows that they are subject to them. But a user subject to hellbanning - or, for that matter, the annoy-user measures such as slowbanning[1] or errorbanning[2] - would not know they are subject to them. They can log out and not see these things, and before anyone so much as breathes 'by IP address' (:P) I would remind them that IP addresses are not reliable and that such things will cause people to be punished unnecessarily and unfairly.
Especially if, say, it's applied to a university or workplace range where proxies are in place. Getting another IP address is not a problem for anyone determined enough to really cause havoc anyway.
I'm also aware that this concept is absolutely nothing new, I just want to be sure that if I do implement it, it is with the best of intentions and that I put in safeguards to try and prevent it from being any more abused than it could be; I don't want to wrap admins' hands in kid gloves but I don't want to hand them a loaded gun either. This sort of measure is not a first resort for troublemakers, it is a last resort, and I want the system to reflect that.
Thoughts would be appreciated.
Hellbanning, or global ignore, is an option whereby all topics and posts by a user are invisible to everyone except themselves. The idea is that they can post freely without realising that no-one else can see their nonsense.
There are some interesting asides to it:
1. Performance is likely negligibly affected, if implemented in the core. As a plugin it's a bit different but probably not that significant. (It's just way cleaner if I make it part of the core)
2. If the user was once a meaningful participant, it could be awkward to hide all the posts and topics as if they never happened, meaning you almost have to consider making it a filter applied at the post level to block a user's contributions after a given point (which *does* bring in all kinds of performance considerations)
3. There are potential issues with hiding posts - you never actively tell the user that they're being punished, but that's part of the point. Never telling them means they don't know, and beat themselves against a wall until they leave. It also means they never have a way to defend themselves or represent themselves.
Basically, I want to give people tools to be able to manage their communities. I want them to be able to deal with troublemakers and have whatever tools will be able to do that effectively. This is why I want to make the warning system more granular, so that instead of very broad levels of punishment (watched/moderated/post banned), you can have punishments that suit every level of troublemaker, right up from inappropriate signatures and avatars (temporary/permanent removal of specific privileges) through to inappropriate content (various tools that I don't want to mention yet, heh[nb]I have some... interesting... ideas that I don't want to spoil yet but that will really help with dealing with troublemakers IMO), and generally inappropriate behaviour (moderation, inability to login/browse, i.e. bans)
The other matters, removal of privileges etc. are fairly subtle but ultimately quite 'safe' punitive measures - a user who is subject to them knows that they are subject to them. But a user subject to hellbanning - or, for that matter, the annoy-user measures such as slowbanning[1] or errorbanning[2] - would not know they are subject to them. They can log out and not see these things, and before anyone so much as breathes 'by IP address' (:P) I would remind them that IP addresses are not reliable and that such things will cause people to be punished unnecessarily and unfairly.
Especially if, say, it's applied to a university or workplace range where proxies are in place. Getting another IP address is not a problem for anyone determined enough to really cause havoc anyway.
I'm also aware that this concept is absolutely nothing new, I just want to be sure that if I do implement it, it is with the best of intentions and that I put in safeguards to try and prevent it from being any more abused than it could be; I don't want to wrap admins' hands in kid gloves but I don't want to hand them a loaded gun either. This sort of measure is not a first resort for troublemakers, it is a last resort, and I want the system to reflect that.
Thoughts would be appreciated.
| 1. | Delaying the user's page loads. |
| 2. | Throwing error messages to users. |
139
Features / Adding permissions from plugin-info.xml
« on September 19th, 2012, 03:28 AM »
I mentioned yesterday that I would have to look at this, and well, here we are.
This is, interestingly, absolutely required in the long term, so I might as well do it now.
Problem 1: unless permissions are declared in the plugin-info.xml file, there's no way for the system to automate cleanup when removing a plugin. This would be more of a problem if it weren't for problem 2.
Problem 2: even if you declare permissions in your plugin's settings page (using the permissions option or similar), there is a possibility that the main manage-permissions code can remove them again because they're not part of the main permissions code as well.
Consequently, we actually have to declare permissions and add them to the main permissions area, even if you keep all the settings in the plugins area like I've been doing. It sucks, but given the rest of the architecture that's actually the best way to go forward.
What it does mean is that you do need to actively declare your permissions, regardless of anything else. And if you really want to do complex stuff, you can still use the hooks that are there, but you must ALWAYS declare permissions in the plugin-info.xml file.
Even if you're doing byzantine stuff like declaring permissions guests can't have, which isn't in the plugin-info.xml file but only accessible via the hook to keep the structure lean, you still have to put the bulk of permissions stuff in plugin-info.xml.
Here's what the structure will look like - simplest case, like I've added for topic solved.
Code: [Select]
Anyone who's added SMF permissions should recognise all the components of that ;) In case people haven't... let me break it down.
<newperms> is the overall container. If that block isn't found, there's no permission processing to do. If it is, there should be a filename entry, which should cover the language file which contains all the strings for that plugin's permissions.
<permissionlist> is the container for all the permissions. There is another container I'll get onto in a moment.
<permission> declares a new permission. Type is membergroup or board, for whichever it is, name is the core permission name. ownany declares whether it is an own/any permission or not, and if it isn't, the name will be the actual name for allowedTo() tests. Otherwise it'll be the permission + _own and _any, just like in SMF.
classic indicates which group it will be added to in Classic View, simple for Simple View, just like in SMF. I may yet rip this stuff out, don't know yet.
If you need to add a whole new group of permissions, you can do so by also adding the groups container.
For example, if I had wanted to make a new section for Topic Solved entirely, I could have done so with:
Code: [Select]
All the $txt requirements (i.e. what all these should be named) is entirely unchanged from what it is in SMF.
This looks cumbersome but it actually is no more than you'd have written making permissions in SMF (and this is simpler in practice, you just declare it and it works)
This is, interestingly, absolutely required in the long term, so I might as well do it now.
Problem 1: unless permissions are declared in the plugin-info.xml file, there's no way for the system to automate cleanup when removing a plugin. This would be more of a problem if it weren't for problem 2.
Problem 2: even if you declare permissions in your plugin's settings page (using the permissions option or similar), there is a possibility that the main manage-permissions code can remove them again because they're not part of the main permissions code as well.
Consequently, we actually have to declare permissions and add them to the main permissions area, even if you keep all the settings in the plugins area like I've been doing. It sucks, but given the rest of the architecture that's actually the best way to go forward.
What it does mean is that you do need to actively declare your permissions, regardless of anything else. And if you really want to do complex stuff, you can still use the hooks that are there, but you must ALWAYS declare permissions in the plugin-info.xml file.
Even if you're doing byzantine stuff like declaring permissions guests can't have, which isn't in the plugin-info.xml file but only accessible via the hook to keep the structure lean, you still have to put the bulk of permissions stuff in plugin-info.xml.
Here's what the structure will look like - simplest case, like I've added for topic solved.
<newperms filename="lang/TopicSolved-Permissions">
<permissionlist>
<permission type="membergroup" name="topicsolved" ownany="true" classic="general" simple="view_basic_info" />
</permissionlist>
</newperms>Anyone who's added SMF permissions should recognise all the components of that ;) In case people haven't... let me break it down.
<newperms> is the overall container. If that block isn't found, there's no permission processing to do. If it is, there should be a filename entry, which should cover the language file which contains all the strings for that plugin's permissions.
<permissionlist> is the container for all the permissions. There is another container I'll get onto in a moment.
<permission> declares a new permission. Type is membergroup or board, for whichever it is, name is the core permission name. ownany declares whether it is an own/any permission or not, and if it isn't, the name will be the actual name for allowedTo() tests. Otherwise it'll be the permission + _own and _any, just like in SMF.
classic indicates which group it will be added to in Classic View, simple for Simple View, just like in SMF. I may yet rip this stuff out, don't know yet.
If you need to add a whole new group of permissions, you can do so by also adding the groups container.
For example, if I had wanted to make a new section for Topic Solved entirely, I could have done so with:
<newperms filename="lang/TopicSolved-Permissions">
<groups>
<group type="membergroup" column="right" classic="ts_group" simple="ts_group" />
</groups>
<permissionlist>
<permission type="membergroup" name="topicsolved" ownany="true" classic="ts_group" simple="ts_group" />
</permissionlist>
</newperms>All the $txt requirements (i.e. what all these should be named) is entirely unchanged from what it is in SMF.
This looks cumbersome but it actually is no more than you'd have written making permissions in SMF (and this is simpler in practice, you just declare it and it works)
140
Bug reports / Mismatch detector is broken
« on September 19th, 2012, 03:20 AM »
It gets very confused. See attachment. It clearly isn't mismatched but it's complaining nonetheless.
Also, if I save this as a draft, then go to re-edit the draft, it pre-pends a code bbc in front of everything - as if the first code tag is irrelevant.
Posted: September 19th, 2012, 03:18 AM
Also, if I save this as a draft, then go to re-edit the draft, it pre-pends a code bbc in front of everything - as if the first code tag is irrelevant.
141
Bug reports / Permissions UI does not honour illegal permissions properly
« on September 18th, 2012, 04:22 AM »
There is, in the depths of the permissions code a function to set which permissions should not ever be shown to guests.
But it does not honour own/any properly - so even when an _any permission is listed to be denied to guests, it still shows up in the admin panel, for example view_ip_address_any is in the deny-to-guests list but still shows in the guests permissions area.
I cannot confirm whether this is an SMF bug or not, all the cases in SMF itself only ever extend _own permissions to be denied to guests (because they can't have an _own)
But it needs fixing.
(Also, permissions + hooking are sort of borked, I really need to extend it in the plugin-info.xml file to fix other issues related to it but that's something else entirely.)
But it does not honour own/any properly - so even when an _any permission is listed to be denied to guests, it still shows up in the admin panel, for example view_ip_address_any is in the deny-to-guests list but still shows in the guests permissions area.
I cannot confirm whether this is an SMF bug or not, all the cases in SMF itself only ever extend _own permissions to be denied to guests (because they can't have an _own)
But it needs fixing.
(Also, permissions + hooking are sort of borked, I really need to extend it in the plugin-info.xml file to fix other issues related to it but that's something else entirely.)
142
The Pub / Language editing inside Wedge
« on September 18th, 2012, 12:32 AM »
You all know my feelings on editing files, and currently the language editor does just that - even for plugins (eek), and right now it's broken. So it needs an overhaul.
So here's what I was thinking. How about, we store the changed strings in the database and load them when necessary? That sounds awful, but let me temper it with this which only occurred to me today.
We know what files contain what strings, and we know what file is being edited at any one time. So if we keep a record of what strings have been modified in the DB versus the original files, we can add a check to loadLanguage to say 'look, we've asked for <language file x>, has there been any changes to that file?' then load any changes to it after the fact, as it were.
All we then need is a DB table containing language, file, optional plugin ID, and the new string and we're golden. Plus if a given file hasn't been updated, no harm, no foul (and no extra query)
This way we get to allow language strings to be edited (cleanly), without any file edits (which is also a security improvement). I'd also move the registration agreement into the language files too and have them all supported in one clean place.
Thoughts?
So here's what I was thinking. How about, we store the changed strings in the database and load them when necessary? That sounds awful, but let me temper it with this which only occurred to me today.
We know what files contain what strings, and we know what file is being edited at any one time. So if we keep a record of what strings have been modified in the DB versus the original files, we can add a check to loadLanguage to say 'look, we've asked for <language file x>, has there been any changes to that file?' then load any changes to it after the fact, as it were.
All we then need is a DB table containing language, file, optional plugin ID, and the new string and we're golden. Plus if a given file hasn't been updated, no harm, no foul (and no extra query)
This way we get to allow language strings to be edited (cleanly), without any file edits (which is also a security improvement). I'd also move the registration agreement into the language files too and have them all supported in one clean place.
Thoughts?
143
Plugins / Something I started working on
« on September 6th, 2012, 05:24 AM »
I've not been feeling 100%, but anyway, I wanted to kick off with a plugin tonight, just to get back into some semblance of a coding life.
So I figured I'd make a start on something that we might use here and that others might want to use. Colours are configurable from the admin panel, too, because I'm nice like that, and that way it's also preserved across installs of the plugin.
(Still early, this is about as far as I've got... without file edits.)
So I figured I'd make a start on something that we might use here and that others might want to use. Colours are configurable from the admin panel, too, because I'm nice like that, and that way it's also preserved across installs of the plugin.
(Still early, this is about as far as I've got... without file edits.)
144
The Pub / Controversial idea: post moderation on by default
« on September 4th, 2012, 09:24 PM »
I wondered, would it be worth shipping with a moderation rule in by default where people with less than 5 posts (who aren't moderators) are automatically post moderated?
I suspect it would encourage people to understand how the system works by having a working example in there by default?
For those coming from SMF: I totally gutted the post moderation system to be rules-based. For example:
* someone tries to make a new post
* moderate the post if:
1) they have less than 5 posts
2) they are not an Administrator, Global Moderator or Board Moderator
There are other permutations, for example you can push it to moderation if there's x number of links posted, or the user is in other groups or has a given warning level or the post contains certain words. It doesn't really matter exactly what, at this stage, just wondering if it should ship with a default rule set up.
I suspect it would encourage people to understand how the system works by having a working example in there by default?
For those coming from SMF: I totally gutted the post moderation system to be rules-based. For example:
* someone tries to make a new post
* moderate the post if:
1) they have less than 5 posts
2) they are not an Administrator, Global Moderator or Board Moderator
There are other permutations, for example you can push it to moderation if there's x number of links posted, or the user is in other groups or has a given warning level or the post contains certain words. It doesn't really matter exactly what, at this stage, just wondering if it should ship with a default rule set up.
145
The Pub / Print Page
« on August 20th, 2012, 05:25 AM »
I've thought about Print Page recently and have some mixed feelings about it.
Specifically, three things occur to me.
1) It could be a plugin rather than a core feature. The savings for the bulk of forums would be quite significant since robots do often follow nofollow links, they just don't carry link juice through. So removing it entirely would actually save quite a bit of bandwidth in the long run.
2) If it's not made a plugin, it could have permissions attached, e.g. default to be not visible to guests.
3) If it does remain core and doesn't have permissions attached, it at least needs to indicate noindex in the page itself, since right now they still do get indexed.
Also, making it a plugin would mean one less stupid thing that is going to appear in 'how do I configure my htaccess for bestest SEO for my forums' threads.
Thoughts?
Specifically, three things occur to me.
1) It could be a plugin rather than a core feature. The savings for the bulk of forums would be quite significant since robots do often follow nofollow links, they just don't carry link juice through. So removing it entirely would actually save quite a bit of bandwidth in the long run.
2) If it's not made a plugin, it could have permissions attached, e.g. default to be not visible to guests.
3) If it does remain core and doesn't have permissions attached, it at least needs to indicate noindex in the page itself, since right now they still do get indexed.
Also, making it a plugin would mean one less stupid thing that is going to appear in 'how do I configure my htaccess for bestest SEO for my forums' threads.
Thoughts?
146
Off-topic / Randomly I wish I worked in an office
« on August 17th, 2012, 12:36 AM »
I don't currently work in a physical office with other people, but I have done in the past. And for those of you who haven't had the pleasure of communal office space (like a noticeboard in the kitchens), you don't know what you're missing.
Specifically, you get the joy of a shared space where people air their views on society in all sorts of interesting ways - and all sorts of funny signs emerge. The infamous one, of course, is 'You don't have to be mad to work here but it helps'
I suddenly realised I would love to work in an office at present, just because I decided I wanted to put up my own sign:Quote There is also a secondary irony in that, that would have been clear to the people I used to work with in the sub-prime mortgage market, where just about everyone seemed to be trying to lie about their income or whatever to get a mortgage...
I have no idea why I want to put such a sign up, just that I know I want to. I mean, I could still put such a sign up around the house and the other folks here would get the joke. But it's a waste of effort for an audience of three (including me) :/
Specifically, you get the joy of a shared space where people air their views on society in all sorts of interesting ways - and all sorts of funny signs emerge. The infamous one, of course, is 'You don't have to be mad to work here but it helps'
I suddenly realised I would love to work in an office at present, just because I decided I wanted to put up my own sign:
You don't have to be completely cynical of humanity to work here, but it helps
I have no idea why I want to put such a sign up, just that I know I want to. I mean, I could still put such a sign up around the house and the other folks here would get the joke. But it's a waste of effort for an audience of three (including me) :/
147
Off-topic / Game Memorial
« on August 3rd, 2012, 02:43 AM »
OK, so I've been very quiet on the coding front lately, one of those projects has materialised in Game Memorial - http://gamememorial.com/
It's a sort of blog/forum hybrid and it's built on SMF 2.0. The reason it's not Wedge is because 1) I couldn't be arsed porting newBalance to Wedge at this point and 2) I don't want to keep patching it once it's stable, something that can't be guaranteed for an indefinite period with Wedge.
There are some other aspects to this that I'm exploring for how they'll fit into Wedge in future:
* future posting - there is the ability to future-post topics and replies. I have a crude but workable UI for this, which isn't really suitable for Wedge at the present time[1] but I want to explore its applications beyond blogging; I'm a biggish fan of WP having the ability to post blog posts in the future, and it's something Wedge deserves, but I'm fairly certain there are benefits to this for regular forum content too, and that's something I will be exploring. The thing is, I don't want to take a risk with this in mainline Wedge, I want to explore it on my own terms and see how it works in practice for me before I figure out a nice way to integrate it into Wedge (core or otherwise)
* tagging - I know we talked about topic tags for Wedge in the past. I'm not entirely sure how useful it would be so I want to explore that too, though in GM's case it's only on the 'game a day' board.
There's all sorts of nuances related to navigation and so on for these things that I need to try out on a real site and see how I interact with it as well as trying to judge how users interact with it - and again, I think the potential is drastic enough that I don't want to drop that in the core just yet until I understand how it works in a real environment.
There is also the fact that it gives me a goal that isn't directly tied into writing code, and more about exercising other parts of my skills and abilities, which serves as a nice rest from the stresses of coding, and by the time demand implied on me it'll actually *force* me to take a break from being stressed by coding which will hopefully work out the last of the kinks related to burn-out and help reduce it happening in the future.
It's a sort of blog/forum hybrid and it's built on SMF 2.0. The reason it's not Wedge is because 1) I couldn't be arsed porting newBalance to Wedge at this point and 2) I don't want to keep patching it once it's stable, something that can't be guaranteed for an indefinite period with Wedge.
There are some other aspects to this that I'm exploring for how they'll fit into Wedge in future:
* future posting - there is the ability to future-post topics and replies. I have a crude but workable UI for this, which isn't really suitable for Wedge at the present time[1] but I want to explore its applications beyond blogging; I'm a biggish fan of WP having the ability to post blog posts in the future, and it's something Wedge deserves, but I'm fairly certain there are benefits to this for regular forum content too, and that's something I will be exploring. The thing is, I don't want to take a risk with this in mainline Wedge, I want to explore it on my own terms and see how it works in practice for me before I figure out a nice way to integrate it into Wedge (core or otherwise)
* tagging - I know we talked about topic tags for Wedge in the past. I'm not entirely sure how useful it would be so I want to explore that too, though in GM's case it's only on the 'game a day' board.
There's all sorts of nuances related to navigation and so on for these things that I need to try out on a real site and see how I interact with it as well as trying to judge how users interact with it - and again, I think the potential is drastic enough that I don't want to drop that in the core just yet until I understand how it works in a real environment.
There is also the fact that it gives me a goal that isn't directly tied into writing code, and more about exercising other parts of my skills and abilities, which serves as a nice rest from the stresses of coding, and by the time demand implied on me it'll actually *force* me to take a break from being stressed by coding which will hopefully work out the last of the kinks related to burn-out and help reduce it happening in the future.
| 1. | The date picker facility is jQuery UI's. It's 42KB minified before gzipping. I am not kidding. |
148
The Pub / Only display 'Redirect boards' when there actually are any
« on July 23rd, 2012, 05:43 PM »
This is something that's annoyed me a bit about SMF in the past, curious to know what people think.
At the foot of the board index, you get icons indicating whether a board has new posts, no new posts or is a redirect board.
Even if you don't have any redirect boards, it still shows up. I figure it should hide that if there's no redirect boards. It's a trivial enough matter to do since we'll know by that point if we've had any redirect boards.
Thoughts?
At the foot of the board index, you get icons indicating whether a board has new posts, no new posts or is a redirect board.
Even if you don't have any redirect boards, it still shows up. I figure it should hide that if there's no redirect boards. It's a trivial enough matter to do since we'll know by that point if we've had any redirect boards.
Thoughts?
149
Off-topic / The ultimate irony
« on July 7th, 2012, 05:13 AM »
Some readers will probably be aware that behind closed doors we've talked about what licence Wedge should take on board. GPL was mentioned and each time it is mentioned it is ruled out for being incompatible with what we want to do with Wedge in the future.
It is a matter of great irony to me then to hear that the GPL itself as a licence has also been forked. If you do read the news article, do please read all the links including the presentation as to why the GPL is an unwieldy tool.
I did attempt to read GPL.next, but it's too much effort at this point for me to save both it and the GPLv3 and diff between the two to see what it is they've changed/are looking to change.
It is a matter of great irony to me then to hear that the GPL itself as a licence has also been forked. If you do read the news article, do please read all the links including the presentation as to why the GPL is an unwieldy tool.
I did attempt to read GPL.next, but it's too much effort at this point for me to save both it and the GPLv3 and diff between the two to see what it is they've changed/are looking to change.
150
Features / Github & stuff
« on July 6th, 2012, 04:58 PM »
I honestly don't know what to suggest for how you want to use Github. I haven't published anything on there, except for some patches to SimpleDesk and comments on a couple of things.
Re PM popup, what I planned to do was open a popup with a special template of your messages, but I guess if we use the notification system it could be better served by that?
Re PM popup, what I planned to do was open a popup with a special template of your messages, but I guess if we use the notification system it could be better served by that?