Hi John:

Thought I would start a new thread since old one on Hiawatha and Debian was losing its focus.

I see that you have implemented the non-image text changes on this site. I have not downloaded it yet for local testing.

1. A suggestion: change the download name to include some form of versioning with each new release. I wanted to keep the version 2.2 distributable but the same name download caused Debian to add "(copy 1)" to the new download filename and I had to be careful about which I used.

2. The non-image text for the inline code button is "Mono". Not sure how that was derived, perhaps with reference to the Mono font that is fixed width, but "Inline" or "Embed" might be better choices.

3. I suppose the emoticons are important to some readers/writers but they occupy most of the format button line where other formatting capabilities might be added, such as heading choices, indented text, and lists (both numbered and non-numbered).

4. The edit post window is an interesting way of handling this function but it is inconsistent with the add new post function. Is there a special reason for doing so?

5. The edit post window hides the text in the right side of the original post even though it becomes transparent when the mouse is moved out of the edit window.

6. The edit post window starts at a fixed size, allows for width and height adjustment using the tag in the bottom right corner, but loses the changed size when the preview button is clicked.

Chris

Hi Chris:

crustyoz

1. A suggestion: change the download name to include some form of versioning with each new release. I wanted to keep the version 2.2 distributable but the same name download caused Debian to add "(copy 1)" to the new download filename and I had to be careful about which I used.

The binary package download link downloads only the latest stable release and rarely some critical bug fixes. If you need to get the latest changes, better clone the source repository and update locally. This way you will always get the recent version of the source. Also, you can download the recent commits from the web page of the repository.

crustyoz

2. The non-image text for the inline code button is "Mono". Not sure how that was derived, perhaps with reference to the Mono font that is fixed width, but "Inline" or "Embed" might be better choices.

Although this formatting is often used for inline code, it is actually simply formatted with a mono-spaced font. From here is the name "Mono" on the button.

On the other hand, the code block is especially designed for handling source code. For example it is possible to make it with syntax highlighting for different languages.

crustyoz

3. I suppose the emoticons are important to some readers/writers but they occupy most of the format button line where other formatting capabilities might be added, such as heading choices, indented text, and lists (both numbered and non-numbered).

The emoticons are pretty counter-intuitive for use. That is why I put the buttons there. Maybe they can be made as a pull-down menu or something.

crustyoz

4. The edit post window is an interesting way of handling this function but it is inconsistent with the add new post function. Is there a special reason for doing so?

The difference is because when writing new post, the user usually writes big amount of text and checks the preview rarely. While, when editing, the text changes are usually relatively small, but the user checks the preview more frequently. At least I am behaving this way.

Notice that this difference is only for the desktop skins - "Wasp" and "Light". The mobile devices skins have more simple editor, because of the smaller screen area.

crustyoz

5. The edit post window hides the text in the right side of the original post even though it becomes transparent when the mouse is moved out of the edit window.

The editor window can be moved by dragging the header. If you want to check in details the right side of the text you can move it to the left.

crustyoz

6. The edit post window starts at a fixed size, allows for width and height adjustment using the tag in the bottom right corner, but loses the changed size when the preview button is clicked.

The same problem have the SQLite console though. But I simply don't have ideas how to implement a persistent sizes.

Notice, that I am pretty low skilled front-end developer and even worse designer. While changing the back-end is easy and quick, changing of the skins html/css/js costs me huge effort and the evolution of the skins goes very slow.

But the project accepts contributions. If you have reasonable suggestions, simply make them as code and they will be merged to the repository.

- A nice to have feature that I only saw on the cgtalk forums is auto-locking of topics after 1 year of inactivity to prevent necrobumping

This might not be needed for this forum at this time but I'm just throwing it here as I found to be an interesting feature.

- Another idea is regarding threads: When clicking answer to see the previous replies also in the same window. Or you could have a quick reply button and a full reply button and the quick reply shows just this edit window where you input text at the end of the page.

- Also multi quote might have some use. So instead of clicking on the quote button for just one user you click multiple quote buttons, hit answer (or reply) and have all the quoted text from the selected posts. Or multi-quote by paragraphs instead of thread reply ...

- Another feature might be to have a subscription to this topic feature with a configurable frequency (as soon as replies come, daily digest, weekly digest) where the forum sends this via email to the users.

Just my 2c, off the top of my head.

dorel

- A nice to have feature that I only saw on the cgtalk forums is auto-locking of topics after 1 year of inactivity to prevent necrobumping

This might not be needed for this forum at this time but I'm just throwing it here as I found to be an interesting feature.

Actually, I always wondered why on some forums bumping old threads is not encouraged? If some people do it with malicious intent, the people are that need to be punished. But forbidding posting in all old threads actually punishes the innocent users, instead of the malicious one.

Although such a feature is pretty easy to be implemented in the procedure PostUserMessage simply by checking the date of the last post in the thread and generating error message if older than the configured age.

dorel

- Another idea is regarding threads: When clicking answer to see the previous replies also in the same window. Or you could have a quick reply button and a full reply button and the quick reply shows just this edit window where you input text at the end of the page.

- Also multi quote might have some use. So instead of clicking on the quote button for just one user you click multiple quote buttons, hit answer (or reply) and have all the quoted text from the selected posts. Or multi-quote by paragraphs instead of thread reply ...

These both looks as a variety of the same idea - to make possible to read and quote different posts from the thread when answering. It is pretty useful. IMHO, the proper implementation should be on the front-end, using some jS. Or (in the case of "quick replay" form) simply by adding editor form directly to the thread view (for example in the navigation templates: nav_thread.tpl ); The multi-quote function should simply place the selected text with the respective username to the textarea of the editor. Very similar to how the edit buttons work.

dorel

- Another feature might be to have a subscription to this topic feature with a configurable frequency (as soon as replies come, daily digest, weekly digest) where the forum sends this via email to the users.

I have some doubts about intensive use of emails from the web sites and particularly from the web forums. While such features are sometimes useful, it is very easy to cross the red line and to make the web site a nasty source of spam. That is why I limited the use of the emails as much as possible.

So, IMO, maybe the notifications should be implemented as a RSS/Atom feeds. Which is planned to be made for some of the next versions.

johnfound

dorel

- A nice to have feature that I only saw on the cgtalk forums is auto-locking of topics after 1 year of inactivity to prevent necrobumping

This might not be needed for this forum at this time but I'm just throwing it here as I found to be an interesting feature.

Actually, I always wondered why on some forums bumping old threads is not encouraged? If some people do it with malicious intent, the people are that need to be punished. But forbidding posting in all old threads actually punishes the innocent users, instead of the malicious one.

Although such a feature is pretty easy to be implemented in the procedure PostUserMessage simply by checking the date of the last post in the thread and generating error message if older than the configured age.

There are some uses for not bumping though, the issue someone might experience might be resolved or no longer applicable, it might be a tangential issue which of course you can (and should) point to in your own topic and then point to related topic if there are any. There might also be archiving matters like reddit where they won't allow replying after a certain time-but I think that this is because of the way their db backed is planned. Of course its reasonable also to have thread locking on some areas only. For example if the forum had a buy and sell area and both parties have finalized their transactions then an auto-lock might come in handy.

Or instead of locking have a solved/partially solved tag/button. On arch linux forums they say to mark the topic as solved but that is inconvenient for me, the lazy kind :) . Instead of the user editing the post title to say solved better to have a button that will mark a topic as solved and potentially showing which reply from the topic was found useful. The highlighting part seems something a la stack overflow/experts exchange and the counter to this would be that not all issues are necessary solved by the marked thread and other can also provide useful insight.

I'm personally ok with how this forum as is and these points are more or less on the political/administrative side of forum administration than its technical aspects.

Issue: WHen creating a new post and adding three tags and hitting preview it will add for each time the preview is executed, an extra tag. In my case it was asm.

Ah my bad It has to add the extra tag to get it filed under a section. Hmm. Ok :)

dorel

Issue: WHen creating a new post and adding three tags and hitting preview it will add for each time the preview is executed, an extra tag. In my case it was asm.

I see. Will fix it, of course, although it is more a cosmetic flaw, rather than real bug, because at the real submit the duplicated tags are automatically removed.

The misbehavior with the tags handling is fixed. It was a little bit more complex than I though, because needed implementation of pretty complex consistency check and limiting logic.

Because the above logic is pretty complex, and I updated the server without so wide testing, some obscure bugs and crashes are possible. Will be fixed on discovery.

Also, the post editor now have advanced JS editor - it makes the preview without page reload, so the position and the size of the editor window are preserved. In addition, some shortcut keys has been set: Ctrl+Enter makes preview, Ctrl+S saves (submits) the edited post and Escape key closes the editor without saving. Nevertheless, the editor still works consistently with JS switched off, only by not providing the above features.

johnfound

The misbehavior with the tags handling is fixed. It was a little bit more complex than I though, because needed implementation of pretty complex consistency check and limiting logic.

Because the above logic is pretty complex, and I updated the server without so wide testing, some obscure bugs and crashes are possible. Will be fixed on discovery.

Also, the post editor now have advanced JS editor - it makes the preview without page reload, so the position and the size of the editor window are preserved. In addition, some shortcut keys has been set: Ctrl+Enter makes preview, Ctrl+S saves (submits) the edited post and Escape key closes the editor without saving. Nevertheless, the editor still works consistently with JS switched off, only by not providing the above features.

Have not worked with the new version long enough to find bugs, but I do like the post editor function as mainline rather than in a popup window.

crustyoz

Have not worked with the new version long enough to find bugs, but I do like the post editor function as mainline rather than in a popup window.

That is because you didn't try to edit big enough posts.

In addition, I plan to implement some day an automatic synchronization between the source window and the preview in order to scroll automatically to the currently edited line of the text.

Just noticed that this thread shows the following on the main page thread listing:

Observations and suggestions

Started by: dorel Joined: crustyoz johnfound

But, crustyoz started the thread. And is able to edit the thread settings.

So, the Started by data retrieval is not correct.

crustyoz

Just noticed that this thread shows the following on the main page thread listing:

Observations and suggestions

Started by: dorel Joined: crustyoz johnfound

But, crustyoz started the thread. And is able to edit the thread settings.

So, the Started by data retrieval is not correct.

It was a problem with the ThreadPosters cache table not properly filled on database update. Should be OK now.