small-tech / watson Goto Github PK

when running watson I get this error

Step 8 (Delete self) failed on line 239.

I was able to continue by looking at the steps in the watson file itself - but this might cause some people some confusion. I'll do some digging see what the issue is, but wanted to raise it here just so you're aware and in case anyone else experiences it.

For example, in task/install, the script will just fail without displaying any instructions the user to install the elementary-sdk package and if vscodium isn't found on the system, the script will also throw an error instead of continuing.

However, this seems to only occur when task/install is called from the watson script.

To run the flatpak package.

e.g.,

flatpak run com.github.small_tech.comet

• Add script
• Update readme

Given that Flatpaks can be distributed in a decentralised manner, in the spirit of the Small Web, we should make this as easy to do as possible.

Proposed implementation

task/publish

Running this script:

1. Creates (or updates) a web site for the app based on the app metadata in the project.
2. Create (or updates) a flatpak repository for the app and a flatpak.ref and links it to the “Install” button on the site.

The site can then be served with Site.js.

Notes:

• Site is localised.
• People who install it also get updates.

In order to access constants (like the app version), core apps like elementary OS Code use a config.vala.in file that’s configured by Meson during the build process.

Implement this for the Watson template.

e.g.,

src/config.vala.in

namespace Constants {
    public const string GETTEXT_PACKAGE = @GETTEXT_PACKAGE@;
    public const string PROJECT_NAME = @PROJECT_NAME@;
    public const string VERSION = @VERSION@;
}

meson.build:

project(
    '…',
    'vala',
    'c',
    version: '1.0.0'
)

…

conf_data = configuration_data()
conf_data.set_quoted('PROJECT_NAME', meson.project_name())
conf_data.set_quoted('GETTEXT_PACKAGE', meson.project_name())
conf_data.set_quoted('VERSION', meson.project_version())
config_header = configure_file(
    input : 'src' / 'config.vala.in',
    output : 'config.vala',
    configuration : conf_data
)

This seems to only happen from flatpak installs. When the flatpak app is run, the app spawns twice, one icon in plank with the app ID and one icon with the app name.

Even after closing the application, the one process with the app name sticks around for a couple of seconds and then closes by itself. Was unfortunately not able to figure out why this happens yet. The screenshot above demos whats going on.

I've created a sample repo for debugging this, its up here: https://github.com/BharatKalluri/double-icon-flatpak-bug

To launch the app in the supported localisations and take screenshots.

A basic version of https://github.com/small-tech/comet/blob/main/task/take-screenshots

In the core apps that ship with elementary OS, the Application constructor manually sets the locale and binds to the gettext package e.g. in Calculator:

Intl.setlocale (LocaleCategory.ALL, "");
GLib.Intl.bindtextdomain (GETTEXT_PACKAGE, LOCALEDIR);
GLib.Intl.bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
GLib.Intl.textdomain (GETTEXT_PACKAGE);

The constants used come from the configuration file (Config.vala.in):

public const string GETTEXT_PACKAGE = @GETTEXT_PACKAGE@;
public const string LOCALEDIR = @LOCALEDIR@;

And the actual values are substituted in meson.build:

config_data = configuration_data()
config_data.set_quoted('LOCALEDIR', get_option('prefix') / get_option('localedir'))
config_data.set_quoted('GETTEXT_PACKAGE', meson.project_name())
config_file = configure_file(
    input: 'src/Config.vala.in',
    output: '@BASENAME@',
    configuration: config_data
)

However, none of this is shown in the Translations section of the elementary OS developer documentation.

Can someone with better knowledge of all this than me please answer:

• What does the above code achieve, exactly? (And is there a link to a resource that explains it?)
• Is it required for localisation to work?
• If so, should we open an issue for it to be included in the Translations section of the developer guide?
• Should a version of it be included in the project generated by Watson?

Thanks!

• Do NOT use the Publish on AppCenter button at https://developer.elementary.io/ as that leads to the old version of the app submission dashboard.
• Instead, open a pull request at https://github.com/elementary/appcenter-reviews

Unknowns

• I do not yet know whether the Stripe Connect integration via the old dashboard will work with the new one. It seemed to succeed when I went through the process with the old/current one.
• I do not know whether the beta of the new one is ready for use yet https://beta.developer.elementary.io/

Apps generated with Watson should handle universal command-line options (like --help and -v/--version) properly by default.

This should be implemented in a manner that makes it easy for the developer to add further options should they desire (see the core apps, e.g., Code, for an example of a good, maintainable implementation.)

• Handle the handle_local_options signal with a custom handler for -v/--version argument
• Add the project description as the option context summary for use in the --help screen (set_option_context_summary())
• Add the project copyright notice as the context description to be displayed at the bottom of the --help screen (set_option_context_description())

e.g.,

#!/usr/bin/env bash

set -eu -o pipefail

flatpak-builder build com.github.small_tech.comet.yml --user --install --force-clean

• Add script
• Update readme

Related: #20, #19, #7, #5

Go through the tasks in Comet and see which we can port back to Watson.

https://github.com/small-tech/comet/tree/main/task

To launch AppCenter, optionally with a given localisation, to preview how the app will look.

Also include: the functionality for commenting in/out the icon so it appears in the preview.

A basic version of https://github.com/small-tech/comet/blob/main/task/preview-in-appcenter

This is something that’s missing from the elementary starter project also.

Add localisation initialisation code to Application initialiser:

GLib.Intl.setlocale (LocaleCategory.ALL, "");
GLib.Intl.bindtextdomain (Constants.GETTEXT_PACKAGE, Constants.LOCALEDIR);
GLib.Intl.bind_textdomain_codeset (Constants.GETTEXT_PACKAGE, "UTF-8");
GLib.Intl.textdomain (Constants.GETTEXT_PACKAGE);

And add the LOCALEDIR constant to the meson.build

conf_data = configuration_data()
conf_data.set_quoted('PROJECT_NAME', meson.project_name())
conf_data.set_quoted('GETTEXT_PACKAGE', meson.project_name())
conf_data.set_quoted('LOCALEDIR', join_paths(get_option('prefix'), get_option('localedir')))
conf_data.set_quoted('VERSION', meson.project_version())
config_header = configure_file(
    input : 'src' / 'config.vala.in',
    output : 'config.vala',
    configuration : conf_data
)

And add it to config.vala.in:

namespace Constants {
    public const string GETTEXT_PACKAGE = @GETTEXT_PACKAGE@;
    public const string PROJECT_NAME = @PROJECT_NAME@;
    public const string VERSION = @VERSION@;
    public const string LOCALEDIR = @LOCALEDIR@;
}

The colour scheme setup is currently in the MainWindow class.

This is fine unless you want to, for example, parse command-line arguments, do some processing based on them (e.g., load a file) and display, say, an error dialogue. At which point you must duplicate the code to have the dialogue match the person’s colour scheme preference.

Instead, by moving it to the activate method of the Application class, the settings will be active everywhere in the app.

Namespace: Constants.Colors

(Keeping the American spelling as everything else uses it.)

https://marketplace.visualstudio.com/items?itemName=EditorConfig.EditorConfig

This will make VSCodium actually apply the settings that are set in the EditorConfig file that is part of the template.

Currently, you have to add any new vala files you create to the meson.build file manually.

This is error-prone and laborious.

We should be able to discover and add the files automatically in the build script. Any vala file in the project should automatically be built.

Once task/package has been implemented, ensure that the task/build script runs meson build --prefix=/usr again if necessary as, otherwise, you get the following error if you run task/build after task/package:

~/Projects/elementary/comet/build ~/Projects/elementary/comet
ninja: error: loading 'build.ninja': No such file or directory

So check for this in the task/run and task/build scripts and reconfigure meson if you detect that the build.ninja file doesn’t exist. e.g.,

# The ninja build file may be missing if the
# person ran a flatpak build before running this script.
# If so, reconfigure meson.
if [[ ! -f build/build.ninja ]]; then
  meson build --prefix=/usr
fi

Without a releases section, Flatpak / AppCenter does not display or use the app version.