>>148

>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

ugh "More options..."

too much clickable elements! and it doesn't even do anything (Firefox 1.0.7 here)!

out! out!

I notice some weirdness with the CSS changes sometimes. For example, the first post on a -100 page will sometimes have the first character of the post enlarged. >>2 looks something like
\
/>2 until it is mouse-overed or you change the CSS, but then it goes back to large again on refresh. Also can happen with lowercase letters. Some of the field labels also change size from refreshing in a certain CSS versus just switching to it.

>It's all a design & layout question. I'd like to have the interface reduced to what is absolutely neccessary, esp. since I do not think many people really want to even bother or bother very often with the whole markup question.

Why have a name field or link field? For the majority of posts they are not used, or only used for sage. As stated earlier, they are not even needed for the bare minimum of usage. You want to prove it is you posting? Use a gpg signature or something and a third-party extension, it is just fluff that is not needed at all!

I'm all for having a system that is easy to modify to the end-user's wants and needs. However, there are going to be plenty of users that are not hardcore enough to make or use such options. Therefore, the normal functionality should be pretty usable.

People seem to pop-up whenever something that would change the interface to shout it down. They seem to fear any change and normally give no reason other than it would clutter things up or some nonsense. Does the CSS selector -really- get in your way? It is probably a whole ten pixels! Is having the More options thing really ruining your experience, or are you just against it on some principle? Personally, I would move it below the comment text-area or something, as now the tab amounts between the main fields has changed.

>>48

That is an interesting idea, and one that deserves some more thought.

The Futaba template is missing the "No File" checkbox next to the File field in the Post New Thread area.

> Thorough search functionality a-la notchan, using PATH_INFO. This might not be possible without implementing a per-post metadata system though.

I think this not something that needs to be part of the software itself.
Besides, Google mostly provides that function just fine with site:blahblahblah.com blah

Also, what is "user deletion"?

Oh, and please bring back MAX_LINES.

RENZOKU are the flood detection things... even if they are useless MAX_POSTS_PER_MINUTE makes a lot more sense than RENZOKU2

3) was about a string to trigger ID:Heaven, not a constant for the Heaven part (which is already configurable)

Re: email/link field

Just because it works one way on 2ch/whatever does not mean it is the best way. Having 'fusianasan' as the only way to trigger the effect is just narrow-minded. Functions should have descriptive names to the people using them; should we keep the field names in Japanese because the Japanese have them in Japanese? Having all of the applicable things configurable is something that makes sense, and you can easily have both 'fusianasan' and 'show_ip' that work at the same time. Frankly, the combinations of many things into unrelated fields is a design flaw. What if you want to use a name/trip and fusianasan? What if your email address contains the string 'sage'? What if you want to sage a thread, but have an ID still?
I think the confusion of existing users is worth reducing the learning curve and improving the intuitiveness.

I'm not saying that the default behaviour needs to change, but being able to easily configure the strings used allows for easier localization.

I probably misspelled fusianasan too, why should I have to remember something so foreign?

No, but that's not the point.

>>116
Good question! I tried to find out myself but just found some interesting but rather unhelpful links:
http://d.hatena.ne.jp/keyword/fusianasan
http://info.2ch.net/guide/faq.html#G5
http://ansitu.xrea.jp/guidance/?FAQ1

>>54
I really don't understand what the problem with the current system is. You must be confused. ┐('～`；)┌

>>244

Er, that's a feature, not a bug. That's how most GUIs act.

>>216
I remember at least one or two boards on 2ch that used it, though I can't remember which (moon language and such, you see).

I apologize for the dumb question I made at the end of >>218. I forgot that Kareha permasages (not closes) a thread after the limit is exceeded, so there's no need for a hypothetical 1001th post anyway! orz

　　　∧∧
　　（　 ･ω･） 　 　It's late
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／

　　　∧∧
　　（ ･ω･ ） 　 　Good night!
　 ＿|　⊃／(＿＿_
／　└-(＿＿＿_／

　 ＜⌒／ヽ-、_＿_
／＜_/＿＿＿＿／
￣￣

>>101
If that is legit, then fusianasan needs to display IPs just like tripcodes: not bold/strong.

>>244

Er, that's a feature, not a bug. That's how most GUIs act.

> some other trickery

I smell JavaScript coming in about >>90-120

>>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

>>244

Er, that's a feature, not a bug. That's how most GUIs act.

...and admin posts that override all board/thread restrictions (ie, bumping a permasaged thread and possibly even posting in closed threads).

>>201

Yeah, no, maybe. Using secure trips for capcodes also adds extra protections against accidentially misspellingyour capcode and leaving it open to attack.

>>357
by "including," I mean "plus."

>>10
Exactly, but considering a lot of people can't make heads from tails in config.pl, how about a saner default?

>>11
That's true, but if least-popular threads are set to be deleted, instead of oldest-first, you don't have to guess.

>>101
If that is legit, then fusianasan needs to display IPs just like tripcodes: not bold/strong.

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/

>>154
Kami! Nice ID.

>>48

That is an interesting idea, and one that deserves some more thought.

Another topic: since dynamic pages eat up CPU in order to rebuild pages according to URL parameters, what would be the likelihood of the current dynamic thread subpages having a significantly adverse effect in this aspect if a board were to grow to 2ch-sized proportions? Should there be a consideration to make these pages as static as the front page?

Also, let's put out a partition to kill secure tripcodes (unless they originated from 0ch/Futaba) and captcha (until we find a way to implement similar functionality without requiring it in the form of a GIF/PNG image), and add functionality for multiple uploads in one post.

And is there any practical way that Kareha can be modified to run multiple (even nested) boards in a single installation?