> I don't understand the argument for OH NO ANOTHER BUTTON MY WHOLE LIFE IS RUINNED crowd

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.

> The replacement will be an option to select the default markup for a board, which makes much more sense overall.

I agree, this seems to make the most sense. I understand the "More options..." will not be showing up on boards with fixed settings, so I'll shut my mouth from now on. Apologies to all who I've been bothering.

testing #`¦

> The "entire thread" link can easily be changes to link to the files in /res/ instead of going through the script, but that would make it somewhat less convenient when you want to consturct custom URLs, so I haven't done it.

A better solution would be to use mod_rewrite to rewrite all /kareha.pl/$number/ links to /res/$number.html
It schould be a lot faster then running the script and the links stay the same.

test1

That would be a bother too.

> forced fusianasan

that seems kind of evil.

Also, I'd like to ask exactly how Kareha does automatically generates deletion passwords. I'm guessing it's similar if not identical to how it creates ID session codes with a user's IP.

fusianasan + sage test

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

>>123

Noted. I've been struggling with that same problem for naming things internally in the code, and obviously it distracted me from noticing the same problem in the GUI.

>>165

>There's no one English word that does the job of the pseudo-Japanese "sage".

How about "dontbump" or "nobump"? Using "down" is pretty misleading, since sage doesn't bump a thread up nor down; it just stays in its place until a thread below is bumped.

>>167 orz

In reference WAHa's post in http://wakaba.c3.cx/sup/kareha.pl/1127713568/l50

>It's been suggested to change the no-ID-on-email to no-ID-on-sage

That sounds good to me.

Ah, there was an XHTML error in the cutesy capcode, and of Safari won't handle XHTML correctly and die on errors. Gah. Fixed.

Oh, and please bring back MAX_LINES.

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

>>137
I also noticed that you removed the CSS selector in individual thread views. Personally, it seems both the Admin options and Style selector are a bit of a hindrance to the overall layout. Don't get me wrong -- I think the drop-in Style capability is fantastic-- but it just doesn't seem to play nice with the current 2ch page design.

The thing is, don't most or all major browsers these days allow users to change CSS styles from within the application itself? I know Firefox does, at least. Maybe the selector isn't really necessary.

And maybe this: http://wakaba.c3.cx/sup/kareha.pl/1126586277/5

The "Entire thread" link in the top navigation bar of the thread page is still broken.

> Does the CSS selector -really- get in your way?
> Is having the More options thing really ruining your experience,

Yes and yes and I already stated why.

I am sure you know this but text markup takes place on a whole different level than identification/bumping issues. Your comment about pgp signatures is very funny but I will not honour it with a comment.

>>112
We already have the ID function, so why do we need such an egregious compromise of anonymity (and security) like voluntarily exposing your own IP?

>>86

>Why should it?

Because it's one of the two requirements for creating a new thread, and it's a lot more important to have a well-defined topic than to fill in your name.

>It's more convenient if you want to start a new thread, but for those who don't it's one more form to have to scroll by.

Good point.

>Any idea why?

I dunno. I guess it's just another one of Futaba's countless layout quirks.

>>38
Sorry, I guess I should've worded that more clearly. I was referring to the ability for users to delete their own posts. It's counter-productive to discussions when a user deletes his own post and a quick replier later quotes or references it. It also encourages users to be lazy with posting, because they can always go back and hide their mistakes.

> To more closely resemble the 2ch look, how about prefixing thread title headers in the main board page with a 【position:postcount】thingie?

I find the "1. Thread title (1000)" format much more readable in the post list. And for the main titles, I don't see any value is putting the position in there. That serves no discernable purpose.

> And as suggested before, the navigation links on the bottom of individual thread pages should include "Previous 100" (ie, all posts before the first post in the URL) and "Next 100" (ie, all posts after the last post in the URL).

They already do, but only if there are enough posts in the thread for this to make sense. Or, try a short range like 23-27 to see it in action.

> The "First 100" link should also be removed from the bottom of individual thread pages, and there should be a link to to thread-list included below the reply box of each previewed thread on the front page.

I've been wondering about the justifications for which navigation links should go where. 2ch has it pretty much worked out, I'm sure, but I don't quite see why there should be a "First 100" at the top but not at the bottom.

> Change "Del" links to widget buttons.

Would be very ugly. Those buttons are big.

> In order for the CSS selector not to take over the entire header, how about turning it into a drop-down menu?

I was meaning to do that from the start, but there was some problem with gettting it right. I forget what exactly.

> The same could be done with the Admin functions (appearing only after one correctly inputs the password), placing it on the right side of the board and thread title headers (this would also allow admins the convenience of deleting and permasaging threads from the front-page).

Squeeks would prefer to have a separate script for admining. I'm not sure which is the best approach here.

> and would something like this work (given that all boards share the same root directory)?
> >>>>sup/1129153864/1-100
> >>>1129153864/1-100

Maybe, but I don't see the value in adding code for this, given that you can just paste the URL in there.

> P.S. When you mentioned serving dynamic pages in >>46, were you referring to individual thread pages? As I mentioned before, it'd be nice to make the front page as dynamic and flexible as thread pages when it comes to viewing options (via PATH_INFO).

The front page gets lots of hits. This would drive up CPU usage something fierce.

> Oh, and please bring back MAX_LINES.

I still don't think it serves any useful purpose.

I don't know if this is a bug or not, but could you change the Futaba template so that hovering over/clicking on a post header doesn't count as doing the same to the deletion checkbox next to it? Same goes for the "[File Only]" area at the bottom with its checkbox.

> What about a(n) (optional) preview page?

I've been considering that, but it's a goddamn pain to implement. It'd be pretty useful, though. Also, it could include the spell checker someone requested way back at the beginning of time.

> statically linked executable

I have to disagree with this. It should run in perl too.

• If you're running wakaba, obviously perl must be there
• Most hosts that library-poor don't provide compilers (or shell) either

> What about a(n) (optional) preview page?

I've been considering that, but it's a goddamn pain to implement. It'd be pretty useful, though. Also, it could include the spell checker someone requested way back at the beginning of time.

>>214

Point taken. I'll add it as an autoclose option.

>>165

>There's no one English word that does the job of the pseudo-Japanese "sage".

How about "dontbump" or "nobump"? Using "down" is pretty misleading, since sage doesn't bump a thread up nor down; it just stays in its place until a thread below is bumped.

>>167 orz

In reference WAHa's post in http://wakaba.c3.cx/sup/kareha.pl/1127713568/l50

>It's been suggested to change the no-ID-on-email to no-ID-on-sage

That sounds good to me.

About the etyomology of "fusianasan":
http://4-ch.net/nihongo/kareha.pl/1102656968/224-

Oops, here's the screenshot. orz