>>71
forgot to add that turning the CSS selector and Admin functions into drop-down menus and moving them to the right side of board and thread title headers would remove that top bar entirely on the front page.
>considering the default prune behaviour of imgboards
One of the parameters Kareha uses to determine pruning is MAX_POSTS, so even if you sage a thread under this new condition, you still add to the board's total postcount and speed up the process for pruning that thread, regardless of MAX_RES. The only flew is this assumes pruning is based on thread creation date, not popularity (because someone could easily bump a shitty thread and save it from deletion).
I also agree that enabling this functionality would further make threads vulnerable to intentional bumping by trolls. I was sorta envisioning it being used in a mature community where trolling is minimal and quickly weeded out by regulars.
Here's a new idea: how about trying this in reverse? Only "sage" posts are counted in MAX_RES, in which case saging can again be used either in protest or as a courtesy to others. The only problem is that people can then freely bump threads without consequence.
I can't reproduce this on Firefox 1.0.4 nor Safari on the Mac, but that ancient Firebird had a similar problem (but even worse).
Anyone else? Try post with a | in your name.
>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
I fixed the Javascript a bit, and uploaded it for these boards. Try shift-reloading to get the new code, and see if cookies work better now that I'm not using cargo-cult code.
Did you ditch customizable capcodes?
How about placing the Formatting menu to the left or right of the "File: " field? I'd also like to see WakabaMark changed to its real name (Markdown).
A few other considerations:
Small details aside, this is seriously shaping up to be an amazing release. Your efforts are much appreciated, WAHa.
How come this is now the by far biggest thread on this board?
Maybe it's because I'm posting useless replies like this one!
testing #`abcdef¦
Well, there are some issues to consider here:
In the end, people actually enjoy the 0ch quirkiness. I know I do. I know about designing good interfaces, but there's something fun about an interface that is a little bit quirky, as long as it doesn't get in your way, and these things don't.
fusianasan + sage test
So, as Xee is almost done, and I'm mostly waiting for external contributions, I decided it was time to start working on the Legendary Next Update for Kareha and Wakaba.
Only problem is, it's been a long time, and I've forgotten most of what needs to be done. Most of it is mentioned SOMEWHERE on the board, though. So this is your chance to pipe up with your pet feature request, or if you're feeling really helpful, to dig out some old posts that mention things that need fixing.
Hop to it!
ugh "More options..."
too much clickable elements! and it doesn't even do anything (Firefox 1.0.7 here)!
out! out!
>>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?
The Futaba template is missing the "No File" checkbox next to the File field in the Post New Thread area.
> Can't this be somewhere else but the post form?
No, because that would be immensely useless and annoying, because nobody would know it's there, and even if they did, they'd have to go somewhere else every time they wanted to post something using a different markup.
You may want to consider releasing Kareha & Wakaba under some sort of license at this point, just to make sure that the scripts always stay free for people to use.
http://en.wikipedia.org/wiki/Free_software_license
http://en.wikipedia.org/wiki/Software_License_Types#Free_software_licenses
http://en.wikipedia.org/wiki/Copyleft
> You still end up with no way to link the fusianasan post with the name/trip one without IDs enabled (unless the ID method is known and no secret data is used).
You'd figure that people who know what fusianasan is will also know how to trigger IDs.
> You spelled it fusiansan once.
So I misspelled one word once.
Sue me!
> Also, how is Kahera unrivaled when there are still large sites that are not running it? Shiichan is still on world4ch, Thorn on parts of wakachan for example.
Neither world4ch nor Pichan are by any means "large". Also, yes, as Shii said, their webmasters are stubborn.
Okay then, for starters, how about the closing message to exactly look like a post (although it's sad it won't be accesable with >>1001)?
Your browser momentarily regressed to an old bug and then got better? Who can tell?
Running in pure perl would be ideal, portability-wise, but in practice implementing a JPEG loader and saver from scratch in Perl is both a lot more work than anyone wants to do, and the result will also be too slow.
As was already stated, making a statically linked executable lets you distribute pre-compiled binaries that people can just upload along with the script.
A 1001th post would be a bother.
> Wait, why should l50 links be indexed/cached?
Because the only way for the search engine to find the old threads is to go through the l50 links. I'm taking the advice of >>322 though.
> The CSS in the All threads page is unsightly. Is there a way to properly wrap the outer color border(s) around the table of threads?
You need to explain what you're talking about before I can do anything about that. What style, and what does "wrap the outer color border(s) around" mean?
> I still say that the "Navigation: " text is extraneous when people can clearly see what the links do. Also still partitioning for 0ch-style error pages (with displayed user host and all).
It's there because freefloating unlabelled links look weird.
> Now that we do have filesize indicators in the backlog page of mode_message, do you still find it useless to have the red bold filesizes near the bottom of thread subpages?
They're there, but only if you enable pruning by size.
> Does mode_message now work in PAGE_GENERATION => 'paged'?
No. I'm too lazy to figure what that's supposed to do, and I don't think anybody actually wants to use that in the first place.
> Idea: forced anonymous/sage/ID/fusianasan by IP/thread/board/whole site (some of these combinations already exist, I know)?
There's no database to keep IP data in, and I'd prefer to keep the script completely agnostic to IP addresses.
> Finally, I imagine that the permasage/close/delete functions in kareha.pl will be easily interchangeable among the conditions in post_stuff(). Can you confirm this?
No, because I don't know what you mean.
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?
> how about having a third party create extensions for those browsers and freeing up the real estate on the actual page?
What's with this obsession on removing the CSS options? It's a single line, and some of us find it useful.
Real estate? Scroll down.