>>108
fusianasan is a voluntary function to show identity without having to memorize a tripcode. Works on all boards. Reveals your IP, of course...
Another feature I'd like is keyboard shortcuts like Wikipedia. Although you'd have to avoid stuff like Alt-D.
>>178
There will always be pranksters around. This is probably a good example on what matters to trust tripcoders more than anonymous contributors.
Trivia: Here is a list of 2ch kopipe to fool people into using fusianasan:
http://ansitu.xrea.jp/guidance/?fusianasan
>>342
Well, for example, in both forms the text labels are bolded when they shouldn't be, in Futaba and Blue Moon. If you take a look at Blue Moon, the text labels in Create new thread are larger than those in the Reply box.
How about listing what dmpk2k or you have done already?
>>91 Ohshi-, time paradox!
What browser are you using? I think I've tracked down the problem, and it's most likely a browser bug. The ancient Firebird (not fox, even) version I tested at work had the same bug (character set issues in the escape() and unescape() functions). It looks like your browser also doesn't follow the spec for how they are supposed to work.
ugh "More options..."
too much clickable elements! and it doesn't even do anything (Firefox 1.0.7 here)!
out! out!
All right, a beta version with some new features is now installed for this board. It implements a couple of bug fixes, and navigational and 2ch-style improvements suggested in this thread. Try it out, and complain about stuff that doesn't work or doesn't make sense.
I also put in customizable capcodes now. You can define a string of arbitary HTML for the capcode, so you can put whatever kind of fagginess you want in there! Hooray! Try this out by posting with #test.
The good old test thread is still here: http://wakaba.c3.cx/sup/kareha.pl/1099697376/
Er, that's a feature, not a bug. That's how most GUIs act.
>>184
If people are going to decide to use custom names for paramaters, then there isn't much you can do about it anyway, or is there?
>5) Seperation of sage et al from the email field to something else...
This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.
>2) Have the string to sage and fusianasan defined as a constant in config
>3) A specific string for ID:Heaven instead of anything in the email field
As I mentioned above, this would better work if they could be modified within each template in the list of string variable definitions.
>4) Cookie preferences such as "Don't use expanding textarea" which leaves it small or big.. or another option for that choice as well; an option to not save Name/Email automatically; anything else that is useful?
I like this one, as far as saving name and e-mail inputs go. I occasionally browse 4-ch at school, and it'd be nice for just an option to clear cookies when you're done and don't want anyone else to use your name, e-mail, and deletion password.
What the hell is RENZOKU?
P.S. >>151 is RMS
How about listing what dmpk2k or you have done already?
>>Well, then you are out of luck, aren't you? So you want to enter your E-Mail but cannot because then the post wouldn't bump then? Solution: Write it in the comment field, problem fixed.
There is no reason to change well-known keywords for this or even turn this into a frustratingly unconvenient tickbox/checkbox.
Having a specific trigger to trigger ID would also work.
>discussion of only one comment box, then you couldn't talk about sage/fusianasan/whatever
You could only trigger the functions in a specific format, say
:link-sage
:name-blah#faggotlol commentI do not believe this was an actual request, but it is obviously possible and usable. Another way would be escaping keywords that you want to post.
> partition to kill secure tripcodes
Why? If you are going to get rid of secure tripcodes you should get rid of tripcodes by the same reasons. On another note, why have I seen partition instead of petition multiple times?
>So I misspelled one word once. Sue me!
My point was that it is unnesessarily obtuse, not nit-picking that you misspelled it.
>This is a widely used system. There is a very low learning curve here. sage = does not bump thread when replying, that's all there is to know. People can then figure out why it is useful on their own.
You would think there is a low learning curve, but that is not really the case. For example, on an imageboard, what effect do you have making a sage post (with no real content) with prune oldest and a permasage limit? What about prune oldest with a permasage limit that excludes sage replies?
>trigger replacements
I'm not sure what to replace sage with, if anything. Down certainly doesn't describe it (to me it implies the reverse of age, which is not the case). don't_bump or dont_bump? show_host or show_ip works for fusianasan imo... show_ID to trigger ID?
> Reintroduction of "Marked for deletion (old)"
I actually don't like that, and think wakaba should no longer use the futaba style of dropping threads by default. Why not use the least-popular option instead? If a thread is in demand, let it live.
Tell me more about these pre-compiled binaries. I thought that was impractical...I mean, instruction set differences and so on.
I was browsing through some old threads and now they're all gone. :(
> Reintroduction of "Marked for deletion (old)"
I actually don't like that, and think wakaba should no longer use the futaba style of dropping threads by default. Why not use the least-popular option instead? If a thread is in demand, let it live.
Some minor things
1) rename the RENZOKU constants to something that makes sense
2) Have the string to sage and fusianasan defined as a constant in config
3) A specific string for ID:Heaven instead of anything in the email field
4) Cookie preferences such as "Don't use expanding textarea" which leaves it small or big.. or another option for that choice as well; an option to not save Name/Email automatically; anything else that is useful?
5) Seperation of sage et al from the email field to something else...
I think a checkbox works better than putting something in the link field, but that can always be left as working too. It would be nice to know if the name is underlined that it has something other than sage rather than putting the cursor over it and reading the status bar. Strip things from the email field, append (sage) to the Name line?
http://en.wikipedia.org/wiki/Public_Domain
It means anyone can do whatever they want with it. They can't claim copyright, though, since they didn't create it in the first place. They can modify it an claim copyright on their modifications, at least as long as they're significant enough, but that doesn't affect existing works in the public domain.
> This is kinda what I had pushed for earlier in >>52. I think that separating the sage (aka, "don't bump"), fusianasan (aka, "show IP"), and ID:Heaven (aka, "no ID") functions from any particular post elements in the main scripts would be ideal for implementing Kareha in systems where inputting a certain string to trigger these functions is not intuitive (ie, every board outside of the 2ch/Futaba family). These trigger strings (S_DONTBUMP, S_SHOWIP, S_NOID) and their assignment to a certain form field input could be instead implemented individually in each template.
There's no obvious way to do this, since there has to be code that specifically checks a field and takes certain actions long before the template comes into play. It'd take some sort of plugin system to implement it, and I don't think that's quite called for.
Also >>154 is Kami.
Whoops, sorry. I read "close" instead of "permasage".
Permasage on filesize seems pretty silly, yes.
> Pruning set to furthest-back instead of oldest.
I don't like this one. You just have to continually age a topic (until it hits the permasage treshold) in order for it so survive a long time. Normal users might have good reason to ignore simply it, though...
> Size limit instead of post number limit, maybe?
Sounds good.
> I was thinking of setting the default behaviour to never permasage or close threads.
I guess I don't have a strong opinion on this one. As long as the values will be customizable, I don't really care, I suppose.
Also: I just noticed that "¦" in tripcodes will work correctly but turn into "�U" through the cookie on /soc/ but not on the sandbox.
>>354
admin.pl with a separate HTML page in ./admin (so it can be accessed simply by appending "/admin" to the board URL). It should have every possible admin feature available in kareha.pl, including rebuilding caches, modifying the spamlist, and nuking the board.
Copyright only applies to the literal code, not to features, ideas, or algorithm. Patents do, to some extent, but that's not the issue here. Since I'm not going to write the exact same code, there's little they can do.