I didn't know what an outliner was: From the Git page: An outliner is a text editor that organizes information in a hierarchy, allowing users to control the level of detail and to reorganize according to structure. Your notes can have full detail, yet be organized so a casual reader can get a quick overview. Outlining is a great way for teams to organize work.
Concord, our GPL outliner
51–60 of 63 posts
Re: Concord, our GPL outliner
#52I didn't know what an outliner was: From the Git page: An outliner is a text editor that organizes information in a hierarchy, allowing users to control the level of detail and to reorganize according to structure. Your notes can have full detail, yet be organized so a casual reader can get a quick overview. Outlining is a great way for teams to organize work.
Re: Concord, our GPL outliner
#53Earlier quoted context omitted.
The GPL is not about being practical, it's about freedom. That's why it's the only licence I would consider releasing software under.
How does a license being confusing to the people that use it (and somewhat to the people that WROTE it) aid in promoting freedom?
Re: Concord, our GPL outliner
#54Earlier quoted context omitted.
What do you mean by an "order on the edges"? I'm only superficially familiar with graph theory.
In graph theory, one usually has a set of nodes (A, B, C, ...) and a set(!) of edges between the nodes, either directed ((A,B), (A,C), (B,A)) or undirected (in which edge (A,B) implies (B,A), (A,C) implies (C,A), etc.). Sets don't have an order; most graph theory doesn't distinguish between the set of directed edges ((A,B), (A,C), (B,A)) and ((A,C), (A,B), (B,A)). On the other hand, when dealing with trees (aka outli…
I like trees too. I think that as long as computer memory is linear, our serializations are going to be linear, so even when we get holographic displays, our primary abstractions should be linearly serializable (so we don't get lost in leaky abstractions), which means trees. A graph structure built on that would have to be some form of "magic" layered on top, based on links embedded in the tree. Among other possibilities, you can make the "edges" be little independent trees that link to the "nodes".
Re: Concord, our GPL outliner
#55First, the brace and indentation style is extremely unusual and hard to follow. I have never seen this style used in another curly-brace-language project anywhere.
I realize that brace and indentation is a very personal preference, but I've had no trouble following a variety of styles - until this one. Here's an example:
if(c.op.inTextMode()){
c.op.focusCursor();
c.editor.restoreSelection();
}else{
c.pasteBinFocus();
}
The if block and matching else block have different indentation levels? What? That does seem to be the pattern followed in a number of places.How would you follow this style if there is a chain of else-if's? I don't see any examples in the code, but it seems it would have to look like this to be consistent:
if(a){
b();
}else if(c){
d();
}else if(e){
f();
}else{
g();
}
OTOH, this function follows two different indentation styles for its two if/else blocks: this.callbacks = function(callbacks) {
if(callbacks) {
this.root.data("callbacks", callbacks);
return callbacks;
} else {
if(this.root.data("callbacks")) {
return this.root.data("callbacks");
} else {
return {};
}
}
};
Try this quiz: Without loading the code into a brace-matching editor, just eyeball that function and see if you can tell which open brace matches with which close brace.The function could be much simpler too:
this.callbacks = function( callbacks ) {
return callbacks ?
this.root.data( "callbacks", callbacks ) :
this.root.data( "callbacks" ) || {};
};
Also in a half-dozen places or so, the code uses a for..in loop to iterate over an array. This type of loop should never be used with an array for two reasons: If any other code in the page extends Array.prototype the code will break, and the order of iteration is not guaranteed. These loops need to be converted to numeric for loops or $.each() or any similar alternative.One last point that is just a matter of taste, but I think the code would benefit quite a bit if it followed the popular jQuery convention of using a $ prefix on variables that contain jQuery objects.
I love outliners, and I'd really like to contribute to this project, but the code is so strangely formatted that I'd have a really hard time with it. I wonder if the authors would consider adopting a more conventional coding style, or if they just like it the way it is?
Re: Concord, our GPL outliner
#56I've been browsing through the code a bit. It has a few problems. First, the brace and indentation style is extremely unusual and hard to follow. I have never seen this style used in another curly-brace-language project anywhere. I realize that brace and indentation is a very personal preference, but I've had no trouble following a variety of styles - until this one. Here's an example: if(c.op.inTextMode()){ c.op.foc…
Re: Concord, our GPL outliner
#57I've been browsing through the code a bit. It has a few problems. First, the brace and indentation style is extremely unusual and hard to follow. I have never seen this style used in another curly-brace-language project anywhere. I realize that brace and indentation is a very personal preference, but I've had no trouble following a variety of styles - until this one. Here's an example: if(c.op.inTextMode()){ c.op.foc…
I think the programmer was just getting comfortable with coding in an outliner when he wrote that code. I would consider that indentation a bug, when and if I work in those areas, I'll fix the indentation there. Thanks for pointing it out.
Re: Concord, our GPL outliner
#58Earlier quoted context omitted.
The GPL is not about being practical, it's about freedom. That's why it's the only licence I would consider releasing software under.
It's not about freedom, and I'm a bit sick of that Orwellian categorization (War is Peace, Freedom is Slavery, Ignorance is Strength). Unlike other open source licenses which outline your rights, the GPL is a document that is filled with taking rights away. It's also ridiculously complicated, to the point where no one is completely clear on what is or isn't allowed (and the LGPL is even worse). It's not practical and…
It's a document that gives and preserves rights of the end user, which include the right to the source code and the right to modify and distribute.
How could it possibly 'take away' rights? Any rights not in the licence didn't exist in the first place and thus can't be 'taken away'.
A licence is a set of conditions which a code author/owner sets for using his/her code, any 'rights' you have to their code is that of the conditions they set.
If a developer chooses GPL for their code then those are the rights to which you can use their code, no rights have been 'taken away from you' at all, it's not your code.
And it's certainly practical, which I'm certain is the reason that it's the most used open source licence.
One particular aspect which makes it practical from a developer standpoint is that if they release their code under GPL they have the right to source code modifications made to their code as end users of such modifications.
There is no BEST licence, the licence profileration is a direct consequence of our different needs and values.
Re: Concord, our GPL outliner
#59Earlier quoted context omitted.
I think the programmer was just getting comfortable with coding in an outliner when he wrote that code. I would consider that indentation a bug, when and if I work in those areas, I'll fix the indentation there. Thanks for pointing it out.
Ah, thanks, Dave, and I'm sorry I went a bit overboard on my remarks about the code! The project does look promising; now I'm encouraged to check it out some more. :-)
I am a total bugger about formatting code.
The outliner approach is pretty good but not perfect.
If-then-else is the sore thumb, for sure.
Along with try-catch.
But overall, outliners are a huge win for writing code.
Let's be hardasses about this stuff, but also understanding.
I think your approach is perfect.
Re: Concord, our GPL outliner
#60Earlier quoted context omitted.
IANAL, but the spirit seems to be "hey, here's this software, use it how you like, but if you distribute it (including building on it or bundling it in a product) please be kind enough to extend the same freedoms to those you give it to." Using Concord on your site? Offer a link to the source. Modify it to work better with a framework? Offer that modification too. Build an entire product off of it? Well, be prepared…
And most important, no gratuitous incompatibility or user lock-in based on formats. Commercial developers esp ones that raise huge money, tend to try to lock users in. If that's their plan, they can write their own outliner, should that situation ever arise.
GPL seems like overkill given your goal. It will be limited to a niche of either fully open source public applications or completely private/internal applications.