Previous Entry Share Next Entry
Release 0.11.6, and The State of Querki
jducoeur wrote in querki_project
The last post here in the development journal was several months ago, and I have a nasty feeling that some folks might think the project is dead. That's far from the truth: I've been working heads-down during the time, rewriting huge swathes of the system, and things are beginning to re-stabilize.

The main change is a profound rewrite of what actually shows up in your browser window. Querki was originally written in the traditional lots-of-webpages style. That worked kind of okay, but the pages themselves were a horror to maintain and improve. Eventually, I got sick of that, and as mentioned back in September, I decided to switch to rewriting things in Scala.js, the new Scala-to-Javascript compiler.

The rewrite was -- well, a much bigger project than I originally expected. Part of that was because Scala.js turns out to be a rich ecosystem unto itself, and it took a while to deeply internalize it. But mostly, I began to realize that a Scala.js client just wanted to *think* differently from the old system. Instead of the old approach, I wound up completely rewriting Querki's front end as a "single page app" -- a big, complex application where most "page changes" don't actually cause a reload.

On top of that, the new front end demanded new middleware. Where the old system was made of lots of messy templates, blending Scala, HTML and Javascript in something of a hash, the new approach is *vastly* cleaner. The new client, which is a complex full-fledged program unto itself, talks to the back end via clean, well-factored APIs that make sense. (These will probably become the seeds of the eventual open API for programmatic access to Querki.)

So in the end, I wound up rewriting about half of Querki, which is a lot more than I thought I was biting off. But the end result is a thing of beauty: ten times easier to comprehend, develop and maintain. Along the way, I've become a hardcore devotee of Scala.js, and quite involved with the community there. It's great stuff.

This is beginning to show up in new features that I had been putting off because they were too much of a pain in the old system. For example, today's project was adding the new Print View Property -- that would have probably taken two days of effort in the old Javascript, but took only a few hours with the new Client. (And comes out as probably a third as much code.)

This Property can be added to any Model or Thing as usual. It is an alternate View to use when you print a Thing out, so that you can Print using a somewhat (or completely) different layout and data than what you see on screen. I needed it for the LARP that I'm running at the end of the month, but I suspect folks will find it generally useful. Related to that is a new "Print..." option on the Actions menu. Due to browser limitations, you need to use this instead of printing from the browser's own menus in order to get the Print View.

The other big change -- and really, the main motivation for the rewrite -- is a complete rewrite of the Model Designer / Advanced Editor. This had been largely unchanged since the early days of Querki, and quite frankly it has always sucked. I had been putting off a rewrite because the thought of trying to build something that complex in Javascript was, frankly, intimidating. (Even in Scala, it's a big, complex system.) The new version feels somewhat similar, but changes lots of details to make the workflow for designing Models *vastly* easier than it used to be. It's not perfect yet, but it's finally decent, and will be improving much more quickly now that the code no longer sucks.

None of this is available by default quite yet. Since release 0.11.0 (about a month ago), the new Client is in "soft launch", living side-by-side with the old UI; some of the less-common pages haven't been converted over yet, so the new Client isn't quite complete. But it's probably 90% of the way there. If you'd like to try it out, you just have to muck with your URL, to stick a hash in the right place. For example, the URL for my personal shopping list Space is "". If I change that to "" -- adding a hash after the last slash -- it quietly switches over to the new UI.

Don't expect things to look much different -- the new UI deliberately looks as much as possible like the old one, and you have to look at the URL to be sure which one you're in. But it works totally differently. Note that the initial load of the new client may take a little while, because it's about 2 Meg all told. But after that, it should be lightning-fast compared with the old UI, because it loading much less for each page. (And once you've loaded the new Client into the browser cache, things start up quickly.) It's a particular win on mobile: after you get past that initial load, everything is much snappier than it used to be.

Anyway, I'm currently focused on finishing up the Client, as well as adding features I need for that LARP. Once that's all done I'll be adding some more documentation -- and then, on to Beta...

  • 1
I was wondering why you weren't stuffing the Print view into the appropriate @media css... until I reread and saw that print view can have separate -data- as well. Yeah, shame about having to do it through the app UI instead of the bultins, but given the above, it makes sense.

Yeah -- doing the @media stuff was already possible, using a Querki Stylesheet (which is simply CSS), and by default printing from Querki elides a lot of shouldn't-be-printed stuff that way. The point of Print View is that you sometimes want to print in a way that is quite different from what you are showing on screen.

In the case of ARC, the Character page is a big, complex, GM-facing thing that shows *everything*, but the printout wants to be what we are handing to the players.

As for the builtins -- I was kind of appalled to discover that, after this many years, the hooks for managing printing are still *terrible*, and badly under-spec'ed. Heck, there isn't even a good way to control headers and footers, much less reliably intercept the print event and change the content being printed. This is one of those areas where HTML5 is still *way* behind Flash, I'm afraid...

  • 1

Log in

No account? Create an account