>>32

Your browser momentarily regressed to an old bug and then got better? Who can tell?

>>22

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.

How about listing what dmpk2k or you have done already?

1. Split threads and posts into separate tables. You're repeating the lasthit and parent column over and over.

/-100 shows the first post two times.

>>191

Thanks for reminding me that I need to fix the CSS for the captcha!

>>n74,76

It's good for referencing replies, too.

The "always show the first post" behaviour is sort of confusing at first. It seems more intrusive than useful.

In mode_image: shouldn't the board title be in <h1>, and the post headers in <h2>?

>>259

Fixed.

>>260-261

The test script doesn't try to handle charsets at all at the moment.

> and/or let your oldtime users tell newbies.

Like so? http://wakaba.c3.cx/soc/kareha.pl/1124991549/7

> Is it intentional that thread links without a trailing slash

Uh, I was wondering the same thing. I'm not sure. I guess I should fix that.

PS: I always wanted to say this: The # anchors on the TiddlyWiki automatically scroll me (FF, 1.0.7) just below the actual text box of the entry. Is that a bug, a feature or... ?

I meant Remote host adress instead of IP.

durr hurr

At least i got 350

PS: I always wanted to say this: The # anchors on the TiddlyWiki automatically scroll me (FF, 1.0.7) just below the actual text box of the entry. Is that a bug, a feature or... ?

Hey, I just noticed this: where did the admin link go? Or are you working on a separate interface already? :D

Uh, kind of a bug. I really should fix it, but, lazy.

> Making them configurable from site to site is really dumb, because it would create an unthinkable usability mess.

Why? Let people figure out things themselves, if they are so keen on changing their keywords. They can get together in their own webmaster threads and figure this out. I don't see why this should be solved here.
Of course I think this is a dumb idea in the first place. Nobody needs to know what fusianasan and sage are. Write a FAQ with two sentences about it and/or let your oldtime users tell newbies. Two frickin' words, and you people talk about it as if it were something like making up a new system of romanization!

> Then why not simply boil it all down to the comment field, with trigger strings for inputting the name, e-mail, sage, ID:Heaven, and fusianasan? You can get a lot more minimal with the current interface.

That's a bit too much. You want to talk about sage and fusianasan in the comment field, not trigger it with it.
I suspect you are joking here, though. Design is about what you can take away and still remain optimal conveniency/efficiency on the user part, not about taking as much away as you are technically capable of.

>>275
Heh, I thought you had disabled it manually.

>The File field is almost never there.

Right, and when it isn't, the Formatting menu can still reside on the same line.

The error page in mode_message should more closely resemble that of 0ch (complete with "ERROR!" title).

the text

c < d

causes a <d> tag to be opened, which is not on the list, and therefore all the text until the next tag will be deleted. a better behavior in this case would be to just convert that < to &lt;. you even ought to do this for

a < b

too, despite the fact that b is a valid tag, because who the hell leaves the closing angle bracket out of their HTML tag?

creating the correct regexes for this is an exercise left to the reader.

GDLib for thumbnails: http://wakaba.c3.cx/sup/kareha.pl/1113869490/5

From here on, this thread is about Kareha again:
↓

Text Art's description about auto-linking URLs and >> references is redundant. Not a bad solution with the layout, though (hiding the menu behind "More options..." still bugs me).

The "Entire thread" link on the thread page is missing a "/" at the end.

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?

>>177

> It's not worth comparing until it doesn't break regularly.

The only problem with it is that it doesn't do paranoid file writes. The fact that the entire server occasionally breaks isn't related to how broken the script itself is.

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

The test thread seems to be broken too.

In mode_image: shouldn't the board title be in <h1>, and the post headers in <h2>?

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