Another item I'd like help with:

1. I'd like somewhere to have a list of people who are currently monitoring the chatroom. The database tries to keep track of that. But I don't currently have a good way to display the information. Suggestions are welcomed.

intriguing news! 🙂

i won't be able to help with any of that...

just want to mention the perhaps only thing i can help with: brainstorming. also already done it there, not sure we should bring it here.

The <input type="text"> at the top of the screen, where you enter the message you want to post on the chat → I'd like that box to use all available horizontal space. In other words, I want it to scale to the screen browser screen size. How do I do that?

i'm looking into that now. We'll need to replace that table-based layout with something more modern (flexbox), but it won't be too invasive.

i'm trying to get the chat script running locally now but it appears i'll need to build tcl 8.7 for that, as it's not in my OS's package repos (nor, apparently, do they have the -dev packages needed for the 8.6 headers).

i'm trying to get the chat script running locally now but it appears i'll need to build tcl 8.7 for that, as it's not in my OS's package repos (nor, apparently, do they have the -dev packages needed for the 8.6 headers).

Both the tcl and tk repos are timing out via the web and fossil clone, so i'm currently unable to get the chat script running locally (i apparently need those two to build wapptclsh), but will keep trying.

We'll need to have the chat script in SCM if we're going to collaborate on it. i'd like very much to tackle the header first - where the input field is, and then do a few relatively small things:

• Auto-linking URLs.
• Highlighting text in the form @blah, under the assumption that it's addressing a specific user, to make it more obvious when someone is addressing you directly. Perhaps only highlighting it on a client where the user's name equals blah.
• Certainly various style tweaking/experimentation.

Regarding notifications: i'm not certain whether than can be done without websockets and don't believe that websockets can be implemented without a standalone server (not via CGI).

Regarding flashing the title bar on new messages: i've found a few JS snippets for doing that and will look at that more closely once the input area is cleaned up a bit.

They aren't timing out for me. What's your "fossil remote" output? It should be https://core.tcl-lang.org/tcl and https://core.tcl-lang.org/tk

What's your "fossil remote" output?

i haven't gotten far enough along to use "remote": they won't clone for me:

[pi@pi4b8:~/fossil]$ f clone https://core.tcl-lang.org/tk tk.fossil
Round-trips: 16   Artifacts sent: 0  received: 28938
server says: 522 Origin Connection Time-out
Clone done, sent: 4514  received: 16110491  ip: 104.18.183.65
server returned an error - clone aborted

So far 3 or 4 attempts. The web interfaces are failing with a message from cloudflare claiming that something is wrong ("error 522") on the remote system.

I can access the web interface and a clone is proceeding (albeit slowly) so I've reported it to the person who manages core.tcl-lang.org.

To build Wapp? I think only libtcl is needed. And I think 8.6 will suffice though 8.7 will be faster. But I am not sure because I always have the sources at hand.

I can access the web interface and a clone is proceeding (albeit slowly) so I've reported it to the person who manages core.tcl-lang.org.

i was able to clone it from Richard's mirror. Cloning was fast, but now the rebuild is taking ages (i'm on a raspberry pi 4 until my new NUC box arrives, hopefully this Thursday).

To get the chat up and running in your local environment:

1. Compile and install "wapptclsh" in /usr/bin. This should only require libtcl8.7.a. Tk is not needed.

2. Run "fossil ui --extroot /path-to-fossil-checkout/tools". Substitute the appropriate pathname of course. The idea is that you want the --extroot directory to be the "tools" subdirectory of your local check-out.

3. Give tools/chat.tcl execute permission.

4. Visit http://localhost:8080/ext/chat.tct

Richard, could you please clarify whether the Tcl source is needed, or if an installed Tcl 8.7 will suffice? If a binary will suffice then one of the nightly binaries from https://github.com/tcltk/tcl/actions?query=workflow%3A%22Build+Binaries%22 or from Roy Keene's KitCreator https://kitcreator.rkeene.org/fossil/index may work.

We'll need to replace that table-based layout with something more modern (flexbox), but it won't be too invasive.

There are several options.

If a message contains a URL, I'd like that part of the text to be enclosed in <a>...</a> with an appropriate href=.

Simple implementation: run all inputs thru the Markdown processor.

Simple implementation: run all inputs thru the Markdown processor.

It's not quite black and white:

• The CGI would have to pipe each of its input strings, even if they're only a single letter, to a separate fossil instance. (Sidenote: the /ext environment does not currently pass on the location of the fossil binary to the subprocess, so it would need to be extended to do so.)

• If we returned processed markdown to the clients, i.e. HTML, it would open up the clients to having arbitrary stuff injected in their session, e.g. STYLE tags which could change the appearance of their session. Worst case would be script tags, but (A) i don't think (not certain) that the markdown parser will pass those on and (B) the default CSP would keep them from running because they'd be missing a matching nonce.

IMO the "right(er) thing to do" for this specific context is for the clients to receive plain text messages from the server (like they currently do) and to implement any bare minimum of auto-markup desired for the chatroom. e.g. auto-linking URLs is already implemented (not yet deployed on the live server) and words in the form @foo are highlighted under the assumption that they're a reference to a user name (TODO is to only highlight names of currently-active users and to highlight the current user's name differently so it's easy to see if someone's talking directly to you). Those impls jump through hoops to ensure that only DOM elements generated via the DOM API get put into the DOM, and not tags passed along from another chat member.

That said, it's up to Richard whether he wants to go the markdown route. i won't fight it, i'll just point out the above potential problem and move on.

If I translate the chatroom implementation from a Wapp CGI extension into native C code in the Fossil core, then we would have easy access to the Fossil Wiki and Markdown formatting engines. Additional advantages:

• We would also have easy access to the hash_color() function so that we could color each line of the chat according to the user who sent that particular message, and the colors would automatically adjust for dark-mode skins.

• We can add new privilege letters to enable access to chat. Perhaps "C" for the ability to read/write chat and "D" for the ability to delete chat messages from other users.

• We could potentially integrate with email notification so that if somebody enters an infrequently used chatroom that you are not currently in yourself, you can get an email message alerting you to this fact.

• Having an integrated chatroom feature strengthens the Fossil story of being a one-stop shop for all your project website needs.

I want to continue to keep the chatroom simple, and in particular not be lured by the temptation of having multiple chatrooms per repository. But with chat built-in, perhaps we could implement extensions to the "fossil init" command to create a new repository that is solely devoted to chat. This would allow you to stand up a new chatroom quickly, just by creating a new special-purpose repo.

I have some other business I need to tend to first this morning. But I'll start a new branch that contains chat integrated into the Fossil core as soon as I am able...

I'm getting an error that I don't have permission to use it.

But some general feedback without having used it: I think there's enough chat systems, but a chat system where you can quickly hop on if you have a quick question is definitely useful.

Would it be possible to build this on some open standard, or at least with bridging in mind? E.g. the open Matrix protocol could be used, which then in turn would allow bridging to IRC/Discord/Telegram/Slack/Gitter. I have a project (using Fossil, of course) that uses exactly this setup, to let people join however they want, and allowing them to join directly via Fossil would be great.

Writing a Matrix client is relatively simple, I think it's fine to just piggyback on an existing server (after all, Fossil is also not implementing its own mailserver).

You need to have check-in privileges on the Fossil source repository in order to see the current chatroom prototype.

The Fossil chatroom prototype has no ambition to compete with IRC/Discord/Telegram/Slack/Gitter. Providing real-time comms across multiple chatrooms and wide variety of clients is certainly useful. But it is also complex. There is nothing in the Fossil chatroom idea that prevents people from using these technologies. However, the Fossil chatroom seeks to solve a different problem.

The Fossil chatroom seeks to provide a private space for core developers of a project to communicate in real-time, without any dependencies (and concommitant constraints) from third-parties. It should be as close to zero-configuration as possible. The Fossil chatroom prototype is a very specific solution to a very specific problem. The chatroom is not intended to provide all the features you always wanted to have in a chat service.

Perhaps we should consider calling the Fossil chatroom something other than "chatroom" to avoid confusion?

Thank you for pointing out the Matrix protocol. That was an interesting read. But it is way, way out of scope for this project.

Perhaps we should consider calling the Fossil chatroom something other than "chatroom" to avoid confusion?

"Backchannel"?

"Backchannel"?

This might be too US-specific slang, but how about "the water cooler"?

It's in my British English dictionary...

"Cabal HQ"? 😉

Or just fossil talk?

ETA: misspoke

In Colombia it would be the coffee machine/place. The water cooler place remembered me about Scuttlebutt and its naming related maritime slang for water cooler.

Fossil conference room?

Conference chat?

There was a technology that pre-dated irc and I think it's called "icb", but I can't remember what it stood for. Maybe part of that name could apply to this feature.

Will the chatroom also be possible to get used from command line?

Could a hook - similar to the after-receive on sync rsp. push - be fired for new entries?

These two would probably allow to link with chat channels of other systems if and when needed.

Another came into my mind while reading this thread: Why not implementing it as an MQTT server/service? Then any subscriber would get the last messages like retained messages in MQTT ... just thinking the new Chatroom like one topic, which is '#' in MQTT. Such a standard would make fossil-scm also interesting for other use-cases and it would be easy to bridge to other chat systems this way, too, as needed; e.g. with NodeRed and MQTT nodes from Aedes. Or beside the hook system an MQTT client message to … but this makes it more complicated thinking about security issues and password management.

Can it be considered to also allow this to be a public chat?

I think it would be nice to allow teeing all message to something else if desired, e.g. IRC or Matrix, and also show messages back there. E.g. it could connect to some IRC server, write every message there as a relay bot and also relay all messages back. In case of Matrix, this would even work without having to keep a consistent connection and would be as easy as responding on an HTTP request and performing an HTTP request.

Just thinking that it's always good to bridge communities together rather than cause more fragmentation. For a project, there is nothing worse than several communities that don't interact with each other. E.g. some subset being only on Telegram while another is only in Discord. Bridging it all together makes the community larger and more productive.

Now, I'm not saying that you should write such a bridge - but I think it would be good to design it with briding in mind, so that this can easily be added.

Just thinking that it's always good to bridge communities together rather than cause more fragmentation.

That's why we have the forum. Others are setting up irc rooms and discord chats.

loved your inputs here, @midar3.

sorry about my following scattered thoughts... hope you still can read 'em! 🤪

telegram is a fairly overlooked amazing piece of software that's going to the dark side of "too big" and "too censoring", not to mention it was never really fully open source... but:

it's still an amazing piece of software none the less. very different from all competitors.

they just implemented a voice chat you all should take a look.

they're currently still going full onboard with this "bridging communities" spirit - except for all the censoring (unlike mastodon). and this voice chat is just the most recent and amazing instance.

that being said...

there's no right way to bridge communities today. there could be one, but there isn't.

i do think fossil is already a great tool that helps a bit, but i also think there's a long way to become as global as it could, with just a few tweaks perhaps (a bit contradicting, huh?).

again: somehow merging emails and forums would be the ultimate tweak to work together with something like delta chat and build a HUGE bridge! 🌈

This will be very useful. I'm already using the forum for communication on one project but a chat-like system would be a better model for our usage. Thanks.

chat is perfectly fine, if it's indeed a chat that can grow to be public. even if not right now, since this is chat beta or alpha.

if it's really meant to stay private and small, then i agree on the name change to avoid confusion. someone mentioned scuttlebutt, perhaps that's more like what you envision?i would guess "private chat" is good enough of a description, in this case.

however...

i can't enforce enough how you should take a look at DELTA CHAT if you haven't. by "you" i mean everyone who like the chat idea.

it's messaging done right. the only way it should have ever been done, really. (disclaimer: i never liked irc, as much as i love forums and public places): by using email as protocol.

if it's really meant to stay private and small

It kinda needs to stay small because if 100 people connect to it at once, the hoster is going to be running 100 instances of fossil concurrently. That won't work well on shared hosters which have CPU/memory quotas in place.

it's messaging done right. the only way it should have ever been done, really.

This chat doesn't aim to be messaging done right, but messaging what the sqlite project needs ;). We've been hacking on it heavily the past 48 hours or so and now have, in Richard's words, a "minimally viable" chat system and we're ready to take a break for a day or two.

haha, take all the time off you need!

why the project needs this, exactly? what are the numbers?

edit: and why not simply using delta chat?

anyway, from what i've seen so far, there's a whole lot of things done around sqlite (such as fossil) that's both done right and what it needs not just by coincidence. 😆

why the project needs this, exactly? what are the numbers?

AFAIK, it's just something Richard wanted to facilitate communication with the sqlite dev team. This project and that one have a highly-recursive relationship, and most of the features Richard adds (as opposed to other contributors adding) have their origins in the needs of that project. My own part in the chat room development is that Richard knows i'm a sucker for rabbit-hole mini-projects like this, and he knew full well i wouldn't be able to resist taking on the JavaScript side of it. Until he posted the demo chat room TCL script a few days ago, though, i had no idea that this was going to be a thing.

from what i've seen so far, there's a whole lot of things done around sqlite (such as fossil) that's both done right and what it needs not just by coincidence

It's been my experience that Richard does nothing by coincidence, even if it may initially seem so sometimes. Many times i've seen certain pieces of the project fall into place and thought, "what a coincidence that A and B and C fit together so well," only to later discover/figure out that coincidence played no role.

Update

The prototype Wapp script was extensively improved by Stephan Beal. But it was limited in that it ran as a CGI extension.

I have not ported the prototype to be a Fossil built-in. The latest code on the chatroom-dev branch seems to work, and it currently installed on the Fossil website. The URL is now:

• https://fossil-scm.org/home/chat

In other words, you now omit the "/ext/" from the middle. Data that accumulated overnight in the prototype has been ported over to the new implementation.

Building

No more Tcl/Wapp to mess with. Just rebuild the latest chatroom-dev branch check-in. Then run "fossil ui". You will need to turn on "C" permission for users whom you want to allow into the chatroom.

No other setup or configuration is required.

To Do List

• The "xmsg" field of the transfer JSON now contains HTML ready to be inserted directly into innerHTML. Any formatting work needs to be done on the server side. Not much formatting is done at the moment. This can be improved.

• The transfer JSON now includes the "uclr" field which contains a color name that is appropriate for the background color of each message. The color name is based on a hash of the user name and is responsive to dark-mode skins. The client-side should be enhanced to make use of this color name.

• We need an audio prompt for when new messages arrive. There should be a toggle on the main /chat screen that lets the user turn this audio alert on and off.

• Need to expire old chat messages.

The prototype Wapp script was extensively improved by Stephan Beal.

"Extensively" might be a bit overstated.

it currently installed on the Fossil website

The colors are a nice addition, as was shortening the timestamp. i'll go back and add the full timestamps as tooltips, just for the sake of having them.

We need an audio prompt for when new messages arrive.

i looked into notifications earlier. HTML5 has a notification API but it's still foreign to me.

Need to expire old chat messages.

Rather than having them expire after X time, should we instead keep the last X messages? That way if someone comes into the chat room after it's been idle for 3 weeks, there's still some content/context. It would be trivial to lop off the last message via JS when a new one arrives.

Rather than having them expire after X time, should we instead keep the last X messages? That way ...

Another use for that would be abusing the chat room as a personal reminder list for one-person/few-persons projects.

The prototype Wapp script was extensively improved by Stephan Beal.

"Extensively" might be a bit overstated.

Okay, now we can say "extensively" ;). The latest code supports pasting images directly from the clipboard and drag/drop of files (images or otherwise). Such images/files are left on the client until they tap the send button, so it's possible to abort the send by dropping another file in its place or tapping the Cancel button which appears when a dropped/pasted blob is queued. TODO is hooking up the Cancel feature to the file selection input field, for a similar effect.

I would like to offer a couple of potential audio files that you might want to consider using for messages. I made these for a chat application about 8 years ago; a chat application that has been discontinued for years.

Receive message: https://www.dropbox.com/s/q25dw43aql5anux/receive.wav?dl=1

Send message: https://www.dropbox.com/s/hiih9gyfg1tzr6e/send.wav?dl=1

I own these sounds. Feel free to use them as you see fit.

Kind regards,

Philip Bennefall

Those are nice sounds.

To the implementers: you might not want to have a sound play if the tab is active and you're in an asynchronous conversation with a group. This would be similar to having a skype conversation with someone; the sounds only play if the app is inactive/in the background.

It might be hard, but a browser popup notification may be nice to have.

Both sounds are nice.

I wouldn't want something as intrusive as a browser pop-up. But I think
stephan@ was already looking into something to highlight the tab when
there's activity in the chat.

I wouldn't want something as intrusive as a browser pop-up. But I think stephan@ was already looking into something to highlight the tab when there's activity in the chat.

The ones i found so far require jquery, except for one which seemed to be buggy in that its demo refused to stop flashing when the stop button was pressed ;).

i'm not picky about the notification type. Visual and audio are both fine with me. Either way, it's a learning process - i don't think any of us have ever used JS to play audio or do HTML5 notifications before.

I have used tinycon.js for notifying the user of a change https://github.com/tommoor/tinycon. It can be called to put a tiny numbered badge (think number of unread messages) over the favico. I patched it with a couple of fixes (from the github tracker) and added support for a round bubble rather than a rounded square.

My version is here.

It can be called to put a tiny numbered badge (think number of unread messages) over the favico.

Very nice :), thank you! i will take a look at that.

My version is here.

i'm getting a connection error on that. Thanks to the browser's dumbing-down of the error report i don't know whether it's a DNS resolution or connection problem.

Sigh. It looks like my free DNS provider's domain is offline.

I have uploaded my tip copy to: https://www.cs.umb.edu/~rouilj/tinycon.js

-- rouilj

I have uploaded my tip copy to

Got it, thank you. This is on my to-try list for tomorrow, along with audio notifications

Tinycon is an interesting approach to notification - definitely not intrusive.

The demo page has a flashing icon in the tab bar.

Edit: The icon changes subtly over time to become increasingly redder. Now that is sophisticated.

I wouldn't want something as intrusive as a browser pop-up.

I may not have been clear enough...

I don't mean the late '90s popups. I mean the 'gentle' looking ones that appear in the corner of your desktop OS. They kind of fade in and allow you to click it to take you to the active tab.

That said, it might not be worth the effort, because I think those require permission via the browser to display and run.

The only concern I have about a highlighted tab is that if the tab is not present, you wouldn't see the flash. If you don't have speakers/headphones, you wouldn't hear the sounds. The popup I proposed would notify you in both of those circumstances.

FWIW, I use this firefox plug in quite actively to group tabs together: https://github.com/projectdelphai/panorama-tab-groups

I don't mean to persuade you away from your thinking of intrusive, I just realize I may not have been clear.

... because I think those require permission via the browser to display and run.

Correct. Whether or not it's worth the effort, i can't yet say. The API is relatively involved but not complex.

The only concern I have about a highlighted tab is that if the tab is not present, you wouldn't see the flash. If you don't have speakers/headphones, you wouldn't hear the sounds. The popup I proposed would notify you in both of those circumstances.

i'd prefer to have both flashing and audio, or at least the option of both, but mainly because that's what i'm used to with Google Hangouts.

If HTML5 notifications turn out to be unproblematic then we can do those, too, and maybe disable the other options of HTML5 notifications are enabled (==permission was granted by the user).

stephan@ I think one of the three latest check-ins broke something in
the chat. No messages are loading for me; it's a completely blank screen
except for the message input box, file upload, header, and footer. It
looks like the screen is trying to render something as the footer slowly
steps down the screen.

I think one of the three latest check-ins broke something

i'm unfortunately unable to reproduce it running 2 different instances - the one on Richard's server and one locally. i'm using Firefox and Chromium, though. Can you try it with a non-Safari browser? Are any errors showing up in the dev tools console?

i have an idea about the culprit, but verifying that requires a browser with broken Date support ;). It's feasible that the addition of the timestamp tooltip is using one of the Date functions which Safari chokes on. Can you try changing this line:

https://fossil-scm.org/home/file?ci=696135b65e77b366&name=src%2Fchat.js&ln=65

simply change it to start with:

if(false)

That will disable the timestamp tooltip so we can rule out whether that's the trigger. Then start it up with:

fossil ui --page chat

Noting that the chat messages are currently not properly refresh when it's run that way - Richard was able to reproduce that problem but we don't yet know what causes it. After posting a message to yourself, reload that page to make the message visible. (That refresh problem doesn't happen, for whatever reason, if your fossil is run via a CGI script.)

For the notifications, regardless the technology that will be use, will it notify everyone in the chat-room or just individual that get mentioned (example: with @username) ?

Should it be configurable ?

• Probably the only choice is using cookies on client side.
  (since configuration per user in the repo doesn't exist)

• Probably needs a button on the chat page to access those configuration.

My original plan was to put a "bell" icon beside the send button, and let users click the bell to toggle notifications on and off. When off, there would be a slash through the bell, or something.

I know which popups you mean, and while not as obnoxious as "those"
popups, I would still prefer no popup appearing on the desktop. To be
candid, though, I'm likely more sensitive than most in this regard—I
prefer to seek what I want than have a presumptuous app distract me from
what I'm doing. But you make valid points regarding a highlighted tab
easily being missed. Like stephan@, I'd prefer the audio and tab flash
but, as he also notes, it's a learning process and hopefully we settle
on something appealing to most.

It might be hard, but a browser popup notification may be nice to have.

HTML5 has an API for that, which i read up on earlier but have not yet experimented with. Investigating that is on the TODO list, though.

I'm getting a Not Authorized from the https://fossil-scm.org/home/chat link.

Do you happen to have commit access on the Fossil src repo?

Yes, I have a commit bit.

I'm getting a Not Authorized ...

Richard just fixed that. He added a new permission for chat and your account was not inheriting that one.

There was a permission problem on your account. Should be fixed now.

Chat requires the "C" permission. I set "C" for all "developers". But you were set up as "reader" plus the addition of "checkin". I've changed you to "developer" now.

Okay, great! Thanks, Richard.

Is there any way to try this without having the commit bit?

Download the code, compile it, and run it on your own system.

The latest 2.14 preview release also includes support for chatroom, if you do not want to compile it yourself.

Is it now time to think about adding some more points to the index.wiki page? Integrated forum and chat would be nice to have listed.

https://fossil-scm.org/fossil/doc/trunk/www/index.wiki

Ah, I see forum is mentioned in 1, so maybe chat can be included or both could be broken out to their own point?

Yes, the documentation does need to be updated. And it is worth thinking about. But I'm still focused on code so I'm not planning on doing anything about the documentation for chat just yet. Let me get it closer to feature-complete first, please.

Of course. No rush at all. I’m just putting this out there and didn’t imply it was to be done now. I’m sorry for any implied rush.

Hi Richard, Thanks for creating this chat room.

Would it be possible to set the "role" ARIA attribute to the value "button" on the element contained in the JSON variable "eWho"? This would signal to screen readers that one could click the element and present it as a button rather than as normal text. Right now, it is almost impossible to get the toolbar where you can delete messages locally or globally to show if you do not use a mouse for navigating.

A patch that adds this is presented below:

All the best,

Peter.

Would it be possible to set the "role" ARIA attribute to the value "button" on the element contained in the JSON variable "eWho"?

Done (not yet checked in) and also applied to several other non-button button-like elements. That said, i would be surprised if our popup menu (which has several such buttons) works nicely with non-mouse/non-tap navigation.

Thank you very much, Stephen. The buttons on our current toolbar (the "Delete Message Locally" or "Delete Message Globally") are presented as buttons.

The buttons on our current toolbar (the "Delete Message Locally" or "Delete Message Globally") are presented as buttons.

Those two are genuine buttons, but we have sever others under the new settings menu which are spans acting like buttons, so they now also have that role.

1. Ensure that new messages are read aloud by a screen reader by assigning the "log" ARIA role to the chat message DIV wrapper.

+ @ <div id='chat-messages-wrapper' role="log">

i don't think you'll want that: when the page first loads it can load load any number of posts. Similarly, when it loads older history (also in batches), they're added to the chat area in reverse order (newest first), so they would hypothetically be read in that order.

Ignoring the mass-spamming of a reader device for a moment, should that role be on that particular element? That one holds all other messages. Would it not make sense (aside from the spamming) to put it on each individual message?

(i have zero experience with ARIA, so am just guessing/assuming here.)

aria-label="Settings..." aria-haspopup="true"

Done. Will be checked in with the next batch.

+ //D.attr(btn, 'role', 'button');

Done.

+ check.setAttribute('aria-label', op.label);

Done.

+this.e.setAttribute("role", "alert")

i'm not sure that one's a good idea, either. That widget is used for all sorts of tooltips in /wikiedit and /fileedit, as well as the "?" button in the bottom/left of /chat. It just so happens to also be used for toast messages and, in the case of /chat, two popup menus (which is kind of an abuse of that widget, but it was within easy reach at the time - those might eventually be replaced with more suitable widgets).

(Edit: formatting fix.)

I just couldn't figure out how to only ensure that the message(), warning() and error() functions were the only functions affected

Those 3 all actually use the same popup instance with a "last one wins" policy - so if message() is called immediately after error(), the error toast gets replaced. Not ideal, but our needs are modest :|.

Since they all have the same role and go through the same central routine, this becomes a trivial to do:

Index: src/fossil.popupwidget.js
==================================================================
--- src/fossil.popupwidget.js
+++ src/fossil.popupwidget.js
@@ -266,10 +266,11 @@
   const toastImpl = function f(cssClass, durationMult, argsObject){
     if(!f.toaster){
       f.toaster = new F.PopupWidget({
         cssClass: 'fossil-toast-message'
       });
+      D.attr(f.toaster.e, 'role', 'alert');
     }
     const T = f.toaster;
     if(f._timer) clearTimeout(f._timer);
     D.clearElement(T.e);
     if(f._prevCssClass) T.e.classList.remove(f._prevCssClass);

That will be checked in soon.

Another way to abuse this would be for some sort of buildbot, or CI environment where completion status are communicated. A CLI interface would be quite nice for this, maybe someone with a bit time on their hands might be interested in doing something like that?

Another way to abuse this would be for some sort of buildbot, or CI environment where completion status are communicated. A CLI interface would be quite nice for this, maybe someone with a bit time on their hands might be interested in doing something like that?

Submitting over POST using wget or curl won't work because of CSRF protections but a CLI interface shouldn't be difficult at all. i'm not currently volunteering, but am quite certain that someone could get a CLI version of message posting (as opposed to reading) done within half an hour, an hour tops, and most of that time would be reading through the existing chat.c code to see how the schema is used.

It isn't a chat room, or discussion room... It's a pastebin too!

That's precisely what i intend to use it for: todo list/idea scratchpad/pastebin.

I see an optimization opportunity in the table definition of chat:

Currently (fossil version 2.14 [10085418fe] 2020-12-26 13:46:58 UTC):

CREATE TABLE chat(
  msgid INTEGER PRIMARY KEY AUTOINCREMENT,
  mtime JULIANDAY,
  xfrom TEXT,
  xmsg  TEXT,
  file  BLOB,
  fname TEXT,
  fmime TEXT,
  mdel INT
);

More optimal might be to put the file BLOB column at the end.

CREATE TABLE chat(
  msgid INTEGER PRIMARY KEY AUTOINCREMENT,
  mtime JULIANDAY,
  xfrom TEXT,
  xmsg  TEXT,
  mdel  INTEGER,
  fname TEXT,
  fmime TEXT,
  file  BLOB
);

-- 
Regards,
Kees

More optimal might be to put the file BLOB column at the end.

Done, thank you!

https://fossil-scm.org/fossil/info/fd73e79b8303cc4a

Is it possible to delete just attachments associated with messages? I see this with the stat improvement:

Number Of Chat Messages: 1,338 (1,324 still alive, 23.9MB in size)

I suppose a workaround would be to send messages with only attachments and those could pruned.

Is it possible to delete just attachments associated with messages?

Not currently from the UI. It could be done from the CLI with:

update chat set fsize=0, file=NULL where fsize is not 0;

or similar. If the need arises we could add a button which does that for a specific message.

Hi,

This is my first time to try the chat, as I've been without a computer for a few days on vacation.

Observations from running This is fossil version 2.14 [adc90d82f3] 2020-12-26 20:57:38 UTC on Windows (the 2.14 preview)

1. When there are no messages, or very few, it's difficult to see all the settings options. The last I'm able to read is "left align my messages".

2. If you maximize the browser window and restore to original size with the settings options open, the settings popup doesn't travel with the window adjustments. It may not need to do that, but maybe it could close on its own?

3. When images are sent inline, they appear to display at a very large size, maybe the original size. Maybe it would be better to have a click to show the larger image in a popup window that could be clicked away?

4. If you start up Fossil ui/server, then navigate to /chat and kill the fossil process, subsequent messages won't be sent (obviously), but there's no indication as to why. I THOUGHT with fileedit, there would be a message when trying to preview a diff or save a change. Is it possible to detect when the fossil process is dead for /chat and prevent the message box from being writable? It probably isn't in a local fossil ui scenario but maybe in a fossil server scenario?

5. Does anything affect hits /chat-poll that are not from Fossil /chat services of other people's browsers?

6. I suppose to reset the number count, you would just drop the database and it'll cycle from 1?

I don't know if any one of these are valid concerns, already fixed, or pedantic complaints.

Hi Again,

Now I'm running fossil version 2.14 [5fab875d32] on OpenBSD.

I like the drag and drop to upload files, but the dotted line disappears quite quickly. I thought it was because I wasn't in the right area, but dropping the file anyway uploads the image and I'm able to cancel/send it.

I like the drag and drop to upload files, but the dotted line disappears quite quickly.

It disappears in 2 cases: the mouse events have detected that the drag is no longer over the "drop zone" or the drop has started. We can only detect those events, not influence how they happen.

I thought it was because I wasn't in the right area, but dropping the file anyway uploads the image and I'm able to cancel/send it.

Dropping does not upload immediately: it places the file in the preview area with a Cancel button. Tapping that will discard the file. Tapping the Send button will send the file and any pending message text at the same time.

The size of images preview after dropping have since been limited to something like 45% of the screen's width, so that large images don't shove the rest of the controls off of the screen.

Would it be possible to remove the outline say .10 seconds after the drop starts by using SetTimeout to trigqer the function that removes the dotted line?

Would it be possible to remove the outline say .10 seconds after the drop starts by using SetTimeout to trigqer the function that removes the dotted line?

That leads to ugly race conditions: the user quickly drags the mouse in, then out, then in, then out, all the while we need to ensure that the timer doesn't trigger twice and that it stops if the mouse drags in again. Yes, it's possible, but it gets internally ugly and gains us... what, in terms of functionality/usability?

As it is right now, the browser does all of that timing madness for us: he app doesn't really draw the dotted line, it just toggles a CSS class on and off in response to drag/drop events for that element and lets the browser style it according to whether the drag-related CSS class is set or not:

https://fossil-scm.org/fossil/file?ci=5fab875d3249b119&name=src%2Fchat.js&ln=615-628

All that makes sense. It's not a problem with pikchrshow, because the text area is the entire drag/drop zone.

It disappears in 2 cases:

That makes sense, but the area seems very, very narrow. I see the dotted line and moving ever so slightly to the north causes the line to disappear. Can the drop zone be widened and made taller/higher? Is it worth it?

Dropping does not upload immediately

You're right and that was sloppy of me to characterize as though it uploaded immediately.

Thanks for the replies on the other observations I had.

Can the drop zone be widened and made taller/higher?

Only by making that file selection widget take up more space in UI. Since dropping is likely to be a comparatively case (e.g. it isn't possible on mobile, a prime target for this app), wasting screen space for it doesn't really appeal to me. (That said, if Richard wants it...)

adc90d82f3

That one is ancient by chat's standards, but some of your questions are still valid...

When there are no messages, or very few, it's difficult to see all the settings options. The last I'm able to read is "left align my messages".

If you maximize the browser window and restore to original size with the settings options open, the settings popup doesn't travel with the window adjustments. It may not need to do that, but maybe it could close on its own?

The settings popup is re-using the same widget used for the "?" button popups in wikiedit and fileedit. Patches for a "proper" popup menu would be appreciated, with the caveat that they need to be "pure JS" - not jQuery.

When images are sent inline, they appear to display at a very large size, maybe the original size. Maybe it would be better to have a click to show the larger image in a popup window that could be clicked away?

Similarly: patches for a pure-JS popup image viewer would be gladly received. We have since added an option for disabling inline images, and instead presenting them as download links.

I THOUGHT with fileedit, there would be a message when trying to preview a diff or save a change.

The chat app's UI is much "thinner", without a status bar to report such problems. It reports connection errors using a "toast", but that only stays on the screen very briefly.

Is it possible to detect when the fossil process is dead for /chat and prevent the message box from being writable?

We cannot know if the connection itself is dead - we can only detect that a connection attempt (e.g. sending a post) has failed (but not the real nature of the failure - it might have just been caused by a temporary misalignment of planets and might fix itself in 3 microseconds). Currently the text for such a post will be lost, but that can certainly be improved upon to remember the text until the server responds. That brings with it race conditions with the user, though: when the "send" button is clicked, the message does not (cannot!) be placed directly into the message stream. Instead it is sent to the server, who processes the formatting and assigns it an ID, and we render the message when the next poll of the server fetches it. The sending and the next poll are different connections with no shared state about that particular message. It's perfectly reasonable for a user to start typing a new message while one is in transit, awaiting a poll response, and that's why we cannot simply disable the input field.

Even so: we could lock the edit field for the Submit part of the process. It wouldn't be ideal, but it probably isn't unreasonable. If the submit fails, we can restore the input text.

How exactly does the markdown on chat function?

[see here](https://pikchr.org/home/info/a34c9dbd615a0540)

translates to this on chat:

see here(https://pikchr.org/home/info/a34c9dbd615a0540)

The chat.md page reports:

Text within [...] is parsed and it if is a valid hyperlink target (according to the way that Fossil Wiki or Markdown understand hyperlinks) then that text is tagged.

(might want another pass over what that's saying)

So should my attempt of a link work as it does on the forum?

Separate from this, a 'nice to have' might be the ability to copy message text, with the timestamp and sender.

How exactly does the markdown on chat function?

It currently doesn't. See fossil:/doc/trunk/chat.md.

is parsed and it if is a valid hyperlink target

It doesn't do full-fledged links, and instead parses links in [...] using the older fossil wiki format, so: [https://.... | label goes here] works. It says "markdown" in the docs, but i don't think that's correct.

In any case, it doesn't do currently full-fledged markdown, but will do so as soon as a pressing need for comes up.

So should my attempt of a link work as it does on the forum?

Only if you're using the forum in Fossil Wiki format.

Separate from this, a 'nice to have' might be the ability to copy message text, with the timestamp and sender.

Note that the JS code doesn't have the plain text - it has the server-processed HTML only. Copying it would require that we either copy the raw HTML or that we do something like copying innerText, which eliminates all HTML styling/tags. Also, it would require that we settle on a text syntax for where the user name and timestamp (and which of the 3 timestamps) goes, and trying to get any 4 people to agree on nitpicky layout details is always an adventure.

Yes, it can be done (and it's not much work - just another button in the timestamp popup widget and a tiny routine to collect the to-copy state), but before doing it i want to know exactly which format people expect that copied text to be in, and i want the arguing about that merits of the formats to be done (without me) before i implement it :).

so: [https://.... | label goes here] works.

Sorry, that's incorrect. i looked right at the output of chat and misread it. It does not parse that properly, instead hyperlinking the whole thing except for the braces.

So:

• [remote url]
• [hash]

Work. i don't believe other forms currently do.

We don't support markup in chat, because there is no preview, and so no opportunity to test and refine your input. The only interpretation is to add anchor tags for hyperlinks, which are one of:

• Text that beings with "http://" or "https://"

• Text surrounded by [...]

In the second case, the hyperlink can be in any of the forums acceptable to markup, such as an artifact ID or a relative path or an interwiki link. In the first case, a full fledged URL is required.

My mistake. I was reading that incorrectly, because chat.md was referencing this page:

https://fossil-scm.org/home/md_rules

rules 1, 2, 3:

[display text](URL)
[display text](URL "Title")
[display text](URL 'Title')

I had incorrectly interrupted it to mean websites outside the fossil repo.