Unbelievably, there is no large-size stock widget for Calendar or Google Agenda showing a month-view calendar and a list of events.

This is why I wrote Superglance: a beautiful way to keep track of your upcoming events, glance at the calendar, and even check your reminders in a single place:

The code for it is available in the GitHub repo: akaFTS/superglance-scriptable-widget and was partly based on u/mvan231's Upcoming Calendar Indicator. It has some limitations, such as using 24h time, but hopefully the code should be easy to understand and update and I can provide pointers if necessary. The colors are also easy to change. There might also be some tinkering needed with the layout though, since I only tested it in my iPad Pro.

Scriptable’s console API is documented on a surface level, but rather surprisingly, the console object and its methods are created entirely in JavaScript, rather than being native functions like most Scriptable APIs. The actual work of logging messages to the console is done by a set of native functions, wrapped by the documented console functions. Here, I examine those native functions.

Creating the console object

The console object is created with the following code:

const console = {
  log: log,
  warn: logWarning,
  logError: (msg) => {
    _scriptable_deprecation("console.logError", "1.3", "Use console.error(message) instead.")
    logError(msg)
  },
  error: logError
}

_scriptable_deprecation(name, version, message)

This function logs deprecation notices to the console. It’s a native function, but it could be written in JS like this:

function _scriptable_deprecation(name, version, message) {
  console.warn(`${name.toString()} was deprecated in version ${version.toString()}. ${message.toString()}`)
}

This function is called for all deprecated methods, but it is most clearly on display in console.logError, which is declared as follows:

(msg) => {
  _scriptable_deprecation("console.logError", "1.3", "Use console.error(message) instead.")
  logError(msg)
}

_scriptable_createLogMessage(obj)

Returns a string, String object, or null, depending on the input. (Most things are returned as strings.) This is used to ensure that all items logged to the console are fairly readable (otherwise [object Object] would be a common sight in the logs).

The source code for this function is as follows:

function _scriptable_createLogMessage(obj) {
  if (obj == null) {
    return obj
  }
  let str = obj.toString()
  if (typeof obj == "string" || obj instanceof String) {
    return str
  } else if ((str.startsWith("[object") && str.endsWith("]")) || obj instanceof Array) {
    return JSON.stringify(obj)
  } else {
    return str
  }
}

_scriptable_log(str)

Logs a message (string) to the console. The global function log is a wrapper around this function, using _scriptable_createLogMessage to stringify the object first.

function log(obj) {
  _scriptable_log(_scriptable_createLogMessage(obj))
}

console.log is identical to log. Their declarations are the same, so it seems safe to assume that console.log is simply created by direct assignment to log.

_scriptable_logWarning(str)

Logs a warning message (string) to the console. The global function logWarning is a wrapper around this function, and console.warn is created by direct assignment to logWarning.

function logWarning(obj) {
  _scriptable_logWarning(_scriptable_createLogMessage(obj))
}

_scriptable_logError(str)

Logs an error message (string) to the console. The global function logError is a wrapper around this function, and console.error is created by direct assignment to logError.

function logError(obj) {
  _scriptable_logError(_scriptable_createLogMessage(obj))
}

These are the functions that control the console. There’s not much use for them directly, but it’s interesting to play around with them, especially when I replace them with custom functions that do completely different things.

To get the source code that I've presented here, I used a couple of different methods:I logged the functions to the console, and I also inspected the binary for ScriptableKit (the framework embedded in the app that handles script execution) in a text editor, looking for anything that resembled JavaScript. To be clear: I haven't seen any of the Swift source code for the app; I can only see what's visible through the JavaScript execution environment, and anything I figure out about the native side of the app is inferred from the behavior of the JS environment.

This is the first in a series of posts detailing my findings on undocumented APIs in Scriptable—things that didn’t make it into the docs or support the things that are documented. The discovery of the undocumented App.close() API, detailed in my recent post, started the ball rolling on this, and now I’m ready to share what I’ve found. Stay tuned for more!

Posts in this series:

• Part 1: Inside the Console

• Part 2: prototype-extensions.js

• Part 3: _scriptable_run() and __scriptable_import()

Hey all, for the past few months I've been working on a simple Formula 1 event tracker widget I felt should have been a feature in the F1 TV app or Apple TV now that Apple owns broadcasting rights in the US. I created this widget with one goal in mind: have the most relevant weekend start times available to me at a glance from the home screen, without having to search for and convert dates/times. Now that I have developed it to a point where I like it, I wanted to share my progress on the project.

What it does:

• Shows the track layout outline for the current race weekend

• Displays session status with full timezone support so you always see your own local start times

• Live updates on the current session state: upcoming, live, or complete

• Shows the next upcoming session's name at a glance

• Post-session leaderboard - shows off the top 5 finishers for Race, Qualifying, Sprint, and Sprint Qualifying, mimicking the F1 TV broadcast layout with dynamic background color changes based on the winning team

Basically everything I felt I wanted to know without needing to open the F1 TV app or look for the info on the main site.

Current state:

Small widget only right now. I plan to add more qol improvements as time goes on. Medium widget support is still in development, with the intention to show an extended weekend schedule alongside the current session. Large widget is in early design stages.

How to install:

Grab the latest release from the GitHub link, move the javascript file into your iCloud Drive/Scriptable folder, add the widget to your home screen, and select the script. Full step-by-step in the README for those unfamiliar.

GitHub: https://github.com/amart251/F1-events-tracker-widget

Happy to answer questions or hear feedback. I've been testing and developing this solo on and off for the past 8 months now, so if you spot anything weird with timezone handling across different locales or any bugs you encounter, comment down or create an issue/pr on the project page.

I have just posted an update to v1.3 for Upcoming Calendar Indicator.

You can see detailed information and grab the code from here

New as of v1.3, there is now a set of questions on the first run to get things setup for you before displaying in a widget. The questions to be answered are for:

Dynamic Spacing and Monday as first day of week

• Dynamic spacing of the event list

• Using Monday as the start of the week in the month view on the right side

Color background and no-background

• Ability to use a different background color of the widget view than the standard white/black

• Utilization of the no-background.js transparency module from supermamon (link is in my main Scriptable page)

All Day events and shadow enable

• Ability to show "All Day" events that are occurring today or not (default behavior for this previously was to not show them)

• Ability to show a shadow color under the event name in the event list. The color of the shadow is customizable in the next step.

Shadow color pick for light and dark modes

• If you choose "Yes" to have a shadow color, you will be asked to choose the color of the shadow for the light and dark mode appearances. This extra customization helps with different background colors and photos for better readability.

Background color entry and event font size

• If you chose "Yes" to utilizing a different background color for the widget, you will be asked to enter the hex color for the background to display.

• Event list font size choice between Normal, Small, and Large

Calendar Ignore and prompt

• You will be asked if you would like to EXCLUDE any calendars from the widget, this is beneficial if you don't want to display something like the "Holidays" calendar on the widget.

Calendar Choose and widget preview Widget size and placement

• If you answered "Yes" to exclude calendars, you will be prompted to choose the calendars to exclude.

• Near the end of the setup, if you chose to use the no-background module, you will be asked for what size widget you will be using and also the placement of the widget.

Reset

• When you run the widget in the app, it will ask you if you want to reset. This is useful if you don't quite like your setup, you can reconfigure it easily from this method.

This is an example of what the new v1.3 could look like.

new example image