| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
On a device with a phone keypad, driving Guess by typing numbers rather
than using the arrow keys seems natural. But if you're going to do
that, showing the labels makes it a lot easier. KaiOS doesn't have any
way for the user to control this, so we should default to the friendlier
state.
|
| |
|
|
|
|
|
|
|
| |
Now that we catch JavaScript errors and report them to the user, I could
tell that the way we were detecting the presence of getKaiAd() didn't
work because it caused an alert every time a build without KaiAds was
started. Detecting the presence of a global variable is slightly
tricky, but explicitly looking for it on "window" works and isn't very
ugly.
|
| |
|
|
|
|
|
|
| |
Most KaiOS devices are primarily keyboard-based, so this seems like a
reasonable approach.
I've also switched to specifying boolean values as JSON booleans because
that works now.
|
| |
|
|
|
|
|
| |
Just checking for the getKaiAd() function by doing "if (!getKaiAd ..."
throws a ReferenceError if it's not defined, and now my error box
catches that. Using "if (getKaiAd === undefined ..." seems to be
acceptable, though.
|
| |
|
|
|
|
|
|
| |
It's a bit of a nuisance at the moment if you're trying to get to the
documentation by pressing the up arrow, so I've moved it above the
documentation links, which is where I keep expecting to find it. I
probably want to do some larger-scale menu re-organisation on KaiOS,
though.
|
| |
|
|
|
|
|
| |
This means that you'll get the right font if you one the app page on a
desktop browser (assuming you have Open Sans installed). Also my
Nokia 800 Tough seems to default to a different font (maybe Noto
Sans?) and I'd prefer to have the same font everywhere.
|
| |
|
|
|
|
| |
Kai recommend five to ten seconds, and five seconds is short enough
that I get timeouts when testing that are hard to distinguish from
having screwed up my content security policy.
|
| |
|
|
|
|
|
| |
This is for defence in depth against security holes either in Puzzles or
in the KaiAds API. I haven't found any documentation of what KaiAds'
CSP requirements are, but allowing scripts and frames from *.kaiads.com
seems to be enough to let the test adverts work.
|
| |
|
|
|
| |
As far as I can tell, the KaiStore is quite happy with YY.MM.DD version
numbers.
|
| |
|
|
|
|
|
|
|
|
|
| |
The default behaviour of JSON::PP's encode_json output is to write the
keys of a hash in Perl's natural hash order, which isn't consistent
between runs of the same script due to hash function randomisation.
This causes my build system to complain when successive builds from
the same source revision don't produce the same output.
Easily fixed: JSON::PP already has a switch to ensure consistent
ordering, it's just a matter of finding it and turning it on.
|
| |
|
|
|
|
|
|
|
|
|
| |
The Kai Store makes display of advertisements provided by the KaiAds API
mandatory. I don't want such adverts to be inconvenient for the users,
so I've just gone for adding a menu item that will display one. This is
probably a little too crude, but it's good for testing things.
The actual KaiAds API code is not free software, so it's not included
here. My intention is to add it by hand to the Zip files for Kai Store
uploads. Without it, the advertising code does nothing.
|
| |
|
|
| |
It should be an object, not an array.
|
| |
|
|
|
|
| |
The documentation says it's only needed to override values in the main
manifest, but it's apparently required even if you only support one
locale.
|
| |
|
|
|
|
| |
Even when the virtual pointer is hidden in KaiOS, it still causes :hover
on whatever element is nominally under it, which is confusing. Disable
all the :hover effects as a workaround.
|
| |
|
|
|
|
|
|
|
| |
This only happens if something edits manifest.pl to provide a version
number, but Buildscr can do that. KaiOS manifests are documented as
requiring dotted-decimal version numbers. In fact, the restrictions are
much stricter than that, and unacceptable version numbers can break the
KaiStore developer portal. YY.MM.DD version numbers seem to be
acceptable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
They're proving to be a right nuisance and will probably require a
substantial overhaul to how they work across the entire JavaScript
front-end. I don't think any of the functionality provided by the
dialogue boxes is critical, so in the interests of getting a minimum
viable product actually released I've disabled those features.
In most cases, this just involves commenting out bits of HTML. The
"Custom..." menu item is added by C code, though, so there I've fallen
back to the standard Puzzles way to implement a nasty hack: an
environment variable.
|
| | |
|
|
|
KaiOS (which is based on Firefox OS, formerly Boot to Gecko) runs its
"native" apps in a Web browser, so this is essentially a rather
specialised version of the JavaScript front-end. Indeed, the JavaScript
and C parts are the same as the Web version.
There are three major parts that are specific to the KaiOS build.
First, there's manifest.pl, which generates a KaiOS-specific JSON
manifest describing each puzzle.
Second, there's a new HTML page generator, apppage.pl, that generates an
HTML page that is much less like a Web page, and much more like an
application, than the one generated by jspage.pl. It expects to build a
single HTML page at a time and gets all its limited knowledge of the
environment from its command line. This makes it gratuitously different
from jspage.pl and javapage.pl, but makes it easier to run from the
build system.
And finally, there's the CMake glue that assembles the necessary parts
for each application in a directory. This includes the manifest, the
HTML, the JavaScript, the KaiOS-specific icons (generated as part of the
GTK build) and a copy of the HTML documentation. The directory is
assembled using CMake's install() function, and can be installed on a
KaiOS device using the developer tools.
|
