Playing with applying GitHub - jakubkrehel/skills: A collection of agent skills that help you build great interfaces. · GitHub and some of my own art/UI direction. I think it is feeling friendlier. We need a themes interface, make it super easy to brand the UI. Maybe configurable at the ProductStore level?
1 Like
While general theming is available low-level, I’m thinking we need something more like a typical app: settings for fonts and colors schemes and such. I’ll try that out, with settings in the user dialog in the header. What I’m thinking is we support simple/common changes like that, and leave theme overhauls for the current DB configured theme systems to swap out major things.
Nice… would be interesting to track through the research and design files to see where the ideas for that Team Planner came from (ie which other system, or systems, have something like that).
Building software is becoming more like playing an RPG… all sorts of exploring to see what this strange new land it pieced together from high-level instructions ended up being… and there are monsters to fight along the way as well as treasures to find. 
There is a new repo scheme:
mr-moqui: same
mr-mantle: renamed mr-mantle-usl to mr-mantle, merged in mr-mantle-udm
mr-marble: renamed MrSimpleScreens to mr-marble, merged in MrMarbleERP
mr-boss: renamed ironstone-boss repo to mr-boss (IronStone BOSS name still the same, repo name changes)
Now there are 4 repos instead of 6 for the mr-moqui set (so far), and all begin with mr- to distinguish from Moqui Java repositories.
Sorry for the headache, but I figured this was worth cleaning up sooner than later, more consolidations long-considered and might as well do them now along with changing so much else…
There is a more complete summary of them here:
Be advised: https://smilingfriends.fandom.com/wiki/Mr._Boss
Mr. Boss… nice, not a bad theme for a AI persona for the IronStone BOSS apps, might be fun to add support for that sort of thing.
The “Appearance” dialog is now in place, with a new menu item under the user icon in the header. I think it turned out pretty well, not sure if those are the exact color schemes we want by default. It’s pretty cool to watch it change in the background. It should also default to ‘auto’ for dark/light and match the system theme it grabs through the browser, and uses a few other Quasar features.
I’m bothered by these spots where you select an item and it expands to reveal another item that has the same page content as its parent. Could User Account List go away and you just select Users?
It is ugly… and I think that should be doable client-side, logic being if a “placeholder” screen (Users) has only one child screen active, then don’t show the child screen. IIRC this is a case where there really are more screens there, but not until you select a User, so those are excluded from the menu on the Find/List screen.
I like the org picker and application section labels on this Linear screenshot. Clustering component controls under different topics or areas is an interesting idea. For instance, a number of component menus have “Settings” in them. What if all those were collected under a “Settings” section in the menu instead of being split among applications. What if different components could add to a “Team” or “People” menu? It would be a big change but it could allow components to extend core functionality in a much more seamless way.
It’s not quite recursive self-improvement, but it’s recursive at least…
There are now edit screens specific to entities, services, and screens. I’ve been working on other things and haven’t played with them yet, but the general idea is embedded tools for building apps with Moqui, some of the tools many of us have been wanting for some time.
There’s even a forum now, the first app in a new public-facing component that is a companion to IronStone BOSS: IronStoa PASS (Public Application Software Suite; a little more contrived than Business OS Suite), in the mr-pass repo. There is more planned for that in the mr-boss plans, customer and suppler portals. Eventually it will also include an ecommerce app. The whole thing is designed to run without mr-mantle in place and instead talk to an upstream MR Moqui server that owns the data.
I started with a forum because it was already getting pretty close to hosting all site infra, and I think a public facing git portal like Gitea (which is like GitHub) is another app coming along soon in PASS. I don’t know if we’d really want to move to hosting our own git repos and having reliable infra for a server like that, but it’s pretty close to being able to.
With the Monitor app also in place this is getting closer to having end-to-end tools, especially with Coarchy handling the requirements side of things. CI/CD tools are another natural fit for this expanded version of Moqui, something to run builds and tests and such, and something to send builds to their new homes.
1 Like
We should use Forgejo instead of Gitea. Gitea is on the path to Githubbing itself. But I thought Moqui is Forgejo in this case? Have you looked at Gerrit | Google Open Source Projects ?
GrapesJS in the dev view? (that WYSIWYG email format they have is really cool)
K8S? Horizontal replication? MoquiOperator?
A lot going on here
All we’re using from Gitea or Forgejo would be UI and tooling inspiration, ie AI-assisted idea mining. That is all the external references have been used for so far in the applications (we have Rust and JS lower-level dependencies used/included, but that’s it).
Which UI do you like better between Gitea and Forgejo?
For an architecture check I tried out the latest archive with the release build. It’s turning into quite the thing: ~60MB for .zip, expands to 174MB (of which the ‘moqui’ executable is 110MB, the rest is all the XML and JS and such).
That’s a web server, email server with decent web UI client built in, database server (postgres embedded in the ‘moqui’ executable, gets copied out on run), git server, ssh server, and more plus an ERP system and NextCloud-like groupware suite thrown in for kicks.
The Rust ecosystem and internal tool reuse makes this an incredibly efficient result, and way smaller than the Moqui Java download with equivalent add-ons, except for PDF rendering for which it requires an external copy of Chromium or Chrome that the moqui executable finds and uses (or can download one to bundle with the release archive). If PDF rendering via html is left out (use an alternative) then that dependency goes away at least for that use case (the test-client harness still uses it), and I’m considering an alternative form of PDF rendering using Rust libraries, but not sure how big an issue this will be (and using HTML/CSS for printed documents makes writing and maintaining them much easier than some oddball thing, even like XSL-FO). Anyway, we don’t have the dependency on a JRE of any sort, so that makes a big difference (a nice, big, complex dependency to drop).
Overall, this is looking good to me. I was hoping for an archive size under 100MB, and at 60MB so far it gives us a lot of room to work with for additional functionality without turning it into a monster (ie a ‘monster’ is any ERP system that can’t fit into less than 100MB, and takes more than 1s to start on common server hardware ).
On a side note, Amazon had Ryzen 9900X chips on sale for ~$330 so I picked one up, big upgrade from my Ryzen 7600: Rust develop profile build down from 3:05 to 1:40, full load (with the ~20k l10n records, much faster without) from ~14s to ~8s, and startup time from ~0.4s to ~0.3s. That is probably about the results to expect with these kinds of chips. On my old laptop, a Mac M1 Pro, it is somewhere between these, closer to the 7600 than the 9900X (of course it’s a couple years older).
With Moqui Rust a bigger dev box is helpful, at least when working on the framework or anything in Rust, but if it’s all on the business side outside the Rust code then you don’t need much at all to run and test locally with it. For runtime the small load tests and such so far are looking good, and I haven’t run a big comparison yet but so it’s looking like MR Moqui will put Moqui Java to some degree of shame.
2 Likes