If I can't get jQuery into core, I don't see how you can get mermaid.js into core.

It may not be too difficult to lash it up locally with some JS skin edits maybe some TH1 code. And if not that, then via CGI server extensions for sure.

Others have done the former with JS code syntax highlighers, for example.

I've never been able to get any of those higherlighters to work when I tried them. Admittedly, I don't know anything about web dev.

mermaid also comes in a CLI, it can crank out SVG or PNG on demand...so maybe that is how via CGI to get dynamic images into the wiki?

I've never been able to get any of those higherlighters to work

You probably didn't relax the default CSP, which you'll likely have to do to get this diagramming feature to work, too.

I would prefer to use the venerable PIC language by Brian Kernighan. Probably we would want to do a fresh implementation that rendered to either SVG or an HTML canvas.

I had not heard of that one before, but that would work too! The reason I mentioned mermaid is because its available to use on wikis, tickets and even readme's on gitlab now, which I am quickly falling in love with its wiki ticket capabilities. there is also a mermaid plugin for Redmine. I think it plugs in very simply.

Also mermaid seems to have a very simple way to express flow charts, sequence diagrams, ERD's and even has an experimental git mode that can plot out version branch diagrams.

Anyway, it plugs easily into gitlab and redmine, so just wondering if it could be plugged into fossil pretty easily. Maybe not.

falling in love with its wiki ticket capabilities.

Fossil tickets have wiki capabilities, too.

wondering if it could be plugged into fossil pretty easily.

Fossil's minimalist use of JavaScript imposes few limits on what you can do using JavaScript to enhance the web UI.

That also means it provides a very basic foundation to build upon.

Personally, I like the flexibility.

yes, PIC would be great.

and troff instead of markdown of course ;)

Wikipedia says that the DPIC implementation can output SVG.

While I know that Fossil wiki and tickets can be improved, it probably won't resemble gitlab, redmine, github, etc. I understand things can be shiny outside of Fossil, and sometimes it doesn't take much, but that comes at the cost of maintaining that code and improving on it more and more. There's another thread on the forum from some folks who use as little javascript as possible in their browsers while still using fossil in a pretty decent way/experience. The more complex the codebase, the less options there are for those folks. Also, keep in mind that the target audience for Fossil is SQLite, not necessarily the whole wide world who is looking for a SCM solution.

Perhaps instead of saying that you like gitlab so much, you should consider explaining what it is you like so much about it and why.

I think i remember seeing a video or someone saying they've implemented a kanban style board within Fossil, but I don't know who or how it was implemented. Maybe someone else here will know.

Perhaps instead of saying that you like gitlab so much, you should consider explaining what it is you like so much about it and why.

I just said what I am loving about gitlab...and also some things I love about fossil.

I agree, I don't think fossil is going to keep up UI-wise with other offerings..

Yet, in terms of the SCM, I think fossil has a few thoughtful features that none of them really have. for example the ability very simply click on any two nodes on the timeline and see a diff. Whew, I love that feature there is nothing easy to do that in gitlab that I have found. Or the fact we have an easy way to click an icon to copy the ticket hash for pasting into a commit comment, etc. There are actually quite a few helpful features in fossil related to SCM management. My comments earlier were not meant to bash fossil!!

But while fossil actually may have some of the coolest SCM oriented features the sqlite team has found beneficial, the wiki and ticket system in fossil is limited and lagging behind...in ways that I agree, fossil may never be able to keep up. And I'm not just talking about eye candy, I'm talking about meaningful, useful features.

That isn't necessarily a problem, but perhaps a few simple improvements to fossil's tickets and wikis would help keep it up enough without becoming unreasonably complex to maintain in the code.

For example, syntax highlighting, markup diagramming, etc..

I realize it may be possible to do some kind of customizing to make it work, but throw my hands up on that one, I couldn't get syntax highlighting to work and I doubt I could get diagramming to work.

Due to the nature that fossil is mostly being used by relatively few people and the core developers are primarily interested in how they work with sqlite, the main reason they made fossil to begin with. Hugely beneficial that they shared fossil with everyone to use in whatever state that it is. But unfortunately they are the core developers and don't seem to have that much interest in growing fossil into a broader open product. For that reason I do not expect fossil to be much more than it already is now, with perhaps a few slight improvements over time as the core devs are motivated to add something that won't be too much work or cause any big complexities in the code....all VERY REASONABLE points too...

I actually would love it if something like fossilab existed... where they use fossil for the SCM instead of git. But that didn't happen, like it or not, git has taken over the world in terms of SCM, so any product management systems that have risen up in recent years have been built up around git. Some of them handle SVN and Mercurial too. But mainly they are git, git and more git. It is what it is. Paradoxically, perhaps they have avoided fossil for the mere reason that fossil already includes its own simple project management features built in (wikis, tickets, web server). I have no idea, but that doesn't seem to be happening and fossil doesn't seem to be gaining any steam to be much more then it is right now..which is still pretty darn cool... I mean come on its super cool that you can run a single executable that is free on the internet which includes not only SCM, but also a web server with tickets and wikis and a built in web UI. There is nothing as complete in such a small package anywhere at all. But this very architecture is actually part of why its not going to keep up with git and git is going to take over for decades to come.

In the past few weeks I've been experimenting a lot more with git. Its not so terrible, but i have almost shot myself in the foot already a few times...so that is part of what makes fossil so much better IMHO. its just unfortunate that the tickets and wiki are bit underwhelming.. I can get by, but recent advancements in gitlab's issue management is probably going to win me over.

I think i remember seeing a video or someone saying they've implemented a kanban style board within Fossil, but I don't know who or how it was implemented. Maybe someone else here will know.

Maybe they did, but web programming is not my thing and it would be useless information for me.

That would be me. Link at https://www.youtube.com/watch?v=yhqA98SNXGM.

I probably should dust off the code and re-integrate it. Just after I finish the time dilation machine ;)

Looks really nice!

But unfortunately they are the core developers and don't seem to have that much interest in growing fossil into a broader open product. For that reason I do not expect fossil to be much more than it already is now, with perhaps a few slight improvements over time as the core devs are motivated to add something that won't be too much work or cause any big complexities in the code....all VERY REASONABLE points too...

I know the point you are trying to make, but I think this is a little cut throat. Yes, the development group is small; yes, the wiki/tickets lack, but pull/patches are welcome to improve in ways you see fit. Gitlab ranges in price from free to $100/month/user. Of course they're going to be able to work on gitlab all the time and add features. I don't necessarily think all the features will aide in better development cycles or fewer bugs shipped in various products/projects, though.

I have no idea, but that doesn't seem to be happening and fossil doesn't seem to be gaining any steam to be much more then it is right now..which is still pretty darn cool...

If you're talking about features for Fossil, I'd suggest you review the changelog. I've probably been using Fossil since version 1.30 (probably before that was released) and it's been improved on over the years. I understand only a small portion of those may touch on tickets/wiki things, which is what you're wanting improved.

Anyway, enjoy using your SCM of choice.

Yes! That's it. Sorry for not remembering you and giving you proper attribution.

But unfortunately they are the core developers and don't seem to have that much interest in growing fossil into a broader open product.

Fossil, IMO, has only one "truly core" developer, and that's Richard, a.k.a. drh. His primary concern is the SCM of sqlite, and that has always been a publicly-stated goal of Fossil since he released it in 2007. sqlite is his bread and butter and his full-time job. Fossil has numerous long-time contributors, a few of us since more than a decade, but Fossil is a part-time volunteer hobby for us, not a full-time job. While i can't really speak for the others, i suspect that most of us contribute because we get great use out of Fossil as it is, not because we aim to turn Fossil into the next git/gitlab/github. (Even if we wanted to, there are massive scalability differences between the two app's models which make fossil (IMHO) entirely unsuitable for projects with a scale like OpenOffice or the Linux Kernel.)

Back in 2013/14 i made good progress in porting fossil to a C library before a particularly severe case of chronic RSI effectively removed me from full-time software development and has left me on medical leave for most of the past 5 years (and through summer 2020, at the very least). Unfortunately, the addition of SHA-256 to fossil left libfossil unable to work with new repos, so picking it up now and getting it up-to-date would require more effort than my RSI-plagued hands are physically capable of committing to. As always, though, if someone were to pick up libfossil and run with it, i would happily continue to host it and provide any moral/technical support, with the limitation that my physical capacity for writing code is extremely limited nowadays. Getting it up to date with respect for the current Fossil code would, however, require going through it with a fine-toothed comb, updating not only the hash handling, but any core queries which have been changed notably along the way. Core algorithms like delta and diff generation, and extracting a given version of a given blob, have been effectively unchanged during that time, but there have been many small-scale changes which would require weeding through/porting over (the addition of forum artifact types immediately comes to mind).

How about posting the code as is?

Guys.. nothing "cutthroat" intended. Please stop being so defensive...

I am only stating the obvious. It is very well stated by RH that fossil was built in order to to make sqlite, not to develop a new open ended SCM platform.

Nonetheless fossil has a lot of nice things... I am just suggesting possible improvements that might make it better. I am not equipped nor have the time to fork fossil and improve it myself. I have only three options, switch to gitlab, keep using fossil as is, or beg for improvements on this forum in order to keep using it.

Just watched this. Very cool.

So, this presentation was from nearly 3 years ago. In that time we now have unversioned files (what was called fossil replace in the video. Also, drh just added CGI extensions. The system in the video also depended on TCL. I believe a small TCL environment (JimTCL) has also recently been checked in to trunk.

Between these three recent improvements, and the extensibility within Fossil, it looks like everything is in place to allow people to start building some serious add-ons to Fossil, such as this Kanban board. It also looks like they don't necessarily need to be a part of 'core' Fossil. I'm still trying to learn TCL and TH1, but this area of add-ons interests me.

The one issue I have is that working on things such as Skins and Tickets right now requires a lot of work in the web UI. I would much rather work on these things in my editor of choice. Is there a Fossil command I've missed that lets me pull skins and/or the ticket code out into files, work on them, then push them back into Fossil? I know you can set up an external skin, so it is the last piece about pushing the changes back into Fossil that I am interested in. And the current suggestion of copy/paste, while workable, isn't that elegant. :-) It would be nice if there was a Fossil command that allowed extraction/packaging of UI portions so that they could be easily developed and shared.

With that functionality, I might dedicate some time to working on this style of add-on, but if I have to do it within the confines of the current web UI I would find it highly frustrating.

Thanks.

I believe a small TCL environment (JimTCL) has also recently been checked in to trunk.

If you're referring to this checkin, you've misinterpreted its purpose.

Fossil's "configure" script is just a wrapper to call Autosetup, which is a Tcl-based software configuration system which is superior in some ways to more common alternatives. When "real" Tcl isn't available locally, it falls back to a stripped-down version of Jim, which even in its fully-featured configurations is still much smaller than real Tcl.

I think it'd be a good idea to offer Jim Tcl as an alternative to real Tcl in Fossil's --with-tcl feature, since it's increasingly rare that Tcl is installed on new machines, and it'd be a nice step up from TH1. However, I think we'd want to include a fuller configuration of Jim than ships with Autosetup for this purpose.

Rather than ship two versions of Jim with Fossil, I think we could adjust Autosetup to falls back to our version instead of the stripped-down jimsh0 version normally bundled with Autosetup.

I'm not proposing a third configuration mode, just a fallback case: if real Tcl isn't found in handling --with-tcl in auto.def, use our local Jim Tcl instead.

See also post this post

The DPIC documentation includes the grammar of (its dialect of) the pic language.

Full source available, with as far as I can see suitable license clauses, but I'm not a lawyer.

Regards, Kees Nuyt

dpic can also be found on gitlab.

Regards,
Kees Nuyt