Previous Entry Share Next Entry
Release 1.3.5
jducoeur wrote in querki_project
Mostly getting some bugfixes and small features out of the way before switching my primary focus back to getting running on AWS.


Added the Share menu: in the menu bar, you'll notice a new icon next to the Notifications bell. This is the Share menu, letting you share this Querki page. For the moment, it just includes Share via Email (which opens your native email app with the link pre-filled), but I plan to add Share via Facebook soon, and expect to gradually enhance this. (Yes, I'd like to have Share via LJ, but I honestly have no idea how to do that. It wasn't officially possible last I checked, but that was a fair number of years ago.)

Added $_defining: this is very much a Power Feature, but will matter to folks who try doing more serious programming in QL.

In a typical QL expression, there are several different kinds of contexts. Say that this Expression is defined on My Model, and I'm looking at My Instance:
My Thing -> My Prop.My Function(Parameter)
Inside of My Function, we can talk about:
  • The received context, which in this case is My Thing -- the value passed into the call to My Function

  • The lexical context, which in this case is My Instance -- the Thing that we have fetched My Function from

  • The defining context, which in this case is My Prop -- the value (usually a Property) to the left of the dot

  • And of course, the parameters, in this case Parameter -- anything inside the parentheses
Up to now, My Function could access the received context as $_context, and the parameters as $_1, $_2 and so on.

For the LARP App I'm developing, I found that I needed a function to be able to access the Defining Context (which was previously only available internally) as $_defining, so I could write the new Pronoun function:
Character Gender -> $_defining -> _matchCase(2)
This is called from a higher-level function that defines a part of speech; for example, the function Ze (which produces something like he / she / they) is
So when you call [[Ze]], it calls Pronoun, passing in the "Nominative" Property; Pronoun fetches the value of Nominative from the Gender that this Character points to; finally, _matchCase() (described below) adjust the capitalization.

Don't fret -- this is arguably the most sophisticated single QL expression currently in production, and odds are you'll never need to do anything so intricate. (Indeed, LARPs are one of the most intricate use cases for Querki; they were the original inspiration for it, and push on it hard.) But it's helpful to have the power when it's needed.

The above example mentions the _matchCase() function. It takes a text value, and adjusts its capitalization to match that of this function call. This has been enhanced, so that _matchCase now has an optional parameter, giving the number of stack frames to look up.

So in the above example, we have [[Ze]] calling [[Pronoun]]. _matchCase(2) in Pronoun looks two levels up, and adjusts the capitalization of the pronoun to match the way you called Ze. So if the Character is Male, and you say [[Ze]], you get "He"; if you call [[ze]], you get "he".

This is perhaps the most overly-specific internal function in all of Querki, and will someday be replaced by one defined in QL, but it's not yet possible to do so. For now, it lets you play "Mad Libs" using Querki functions, using functions to define "slots" that get filled in like the Pronoun above, and get the capitalization right simply by capitalizing the function calls or not. It's great for LARP character sheets; we'll see how much other other usage it gets. (Note that _matchCase will almost certainly be relegated to a mix-in App before long, since it is so specialized.)


Fixed Who Can Read on Spaces: I recently removed the ability to add the Who Can Read permission to Properties, since we don't actually *do* anything with it. Unfortunately, the ham-handed change also removed it from Spaces; this is now fixed. Existing security was never endangered; there was just briefly no UI to restrict read access to a Space.

You can now properly edit Text fields on touch screens: for quite a while, the Advanced Editor was kind of broken on touchscreens (phones and tablets), in that you couldn't click on a Text or Large Text field to edit it.
You can now scroll a touch screen without rearranging the Properties: *also* for a long time, the Advanced Editor was really hard to use on a phone, because when you tried to scroll the page, you would often accidentally catch one of the Properties and drag it around, rearranging them in this Model.

Both of these bugs had the same underlying cause: we're using a common library called Touch Punch to make drag-and-drop of Properties work on touch screens. Problem is, we were overloading click and drag that way, to the point where other functions couldn't work. When you tried to scroll the screen, it tried to drag if you started on a Property (and Properties make up most of that screen). When you tried to click inside the text, it would interpret that as the beginning of a drag.

So I've bitten the bullet and made a UI change: there is now a drag handle for Properties in the Advanced Editor. You can't just drag from anywhere: you have to grab the handle (which is pretty obvious) and drag that if you want to reorder the Properties. It's going to take a while for me to adjust my own habits for this -- I'm used to being able to grab anywhere on the Property with my mouse and drag it. But it's necessary to make touch screens work, and touch screens are important.

(Thanks to Xavier, who suggested this change months ago; I eventually realized that he was right, and this was the only sensible answer.)

Fixed _createHere to cope with Parent Properties other than ExactlyOne: this one's pretty obscure, but for the record -- it turns out that the recent _createHere function misbehaved when you fed it a Property that wasn't ExactlyOne. That misbehavior was *very* bad -- it actually mis-wrote the created Thing to the database. I've fixed the immediate bug in _createHere, and made the database reader more tolerant of this slight inconsistency. (Suffice it to say, it would *always* serialize the value as ExactlyOne, even if the Property was, say, a Set -- this caused failures at read time. It now copes with this, and I'm putting in some checks to avoid this happening again.)


Log in

No account? Create an account