PhosphorAnimation::ProfileLoader Class Reference

Scans JSON profile-definition files and registers them with PhosphorProfileRegistry. More...

#include <phosphor-animation/include/PhosphorAnimation/ProfileLoader.h>

Inheritance diagram for PhosphorAnimation::ProfileLoader:

Classes
struct	Entry

Signals
void	profilesChanged ()

Public Member Functions
	ProfileLoader (PhosphorProfileRegistry &registry, CurveRegistry &curveRegistry, const QString &ownerTag={}, QObject *parent=nullptr)
	If ownerTag is empty, a unique per-instance tag is generated.
	~ProfileLoader () override
int	loadFromDirectory (const QString &directory, LiveReload liveReload=LiveReload::Off)
int	loadFromDirectories (const QStringList &directories, LiveReload liveReload=LiveReload::Off, PhosphorFsLoader::RegistrationOrder order=PhosphorFsLoader::RegistrationOrder::LowestPriorityFirst)
	Scan multiple directories in caller-declared priority order.
int	loadLibraryBuiltins (LiveReload liveReload=LiveReload::Off)
QString	ownerTag () const
void	requestRescan ()
void	rescanNow ()
	Rescan synchronously, so a caller that just wrote or deleted a profile file can read the registry back in the same call.
int	registeredCount () const
QList< Entry >	entries () const

Detailed Description

Scans JSON profile-definition files and registers them with PhosphorProfileRegistry.

Shaped like CurveLoader, diverging in two places: an owner-tag constructor parameter, and a synchronous rescanNow() for the consumer that writes profile files and reads the registry back in the same call. Nothing needs the second of curves, so CurveLoader has no twin for it.

There is deliberately no membership accessor here. "Is this path tracked by this loader" is almost never the question a consumer means, and answering it is actively misleading: a path can be tracked here while the registry entry for it belongs to somebody else, including an untagged direct publish. Ask PhosphorProfileRegistry::ownerOf() instead, which is the ownership question and is equally O(1). The distinction prevents a self-poisoning merge: a consumer that folds its own registered profiles back into the registry this loader owns would see them wiped on the next rescan, because the loader clears its OWN tag wholesale. Ownership, not tracking, is what tells the two apart. User curves must already be registered (CurveLoader first). Profiles loaded here are preset templates — settings UIs deep-copy into active profiles.

Constructor & Destructor Documentation

ProfileLoader()

PhosphorAnimation::ProfileLoader::ProfileLoader ( PhosphorProfileRegistry &  registry, CurveRegistry &  curveRegistry, const QString &  ownerTag = {}, QObject *  parent = nullptr  )

explicit

If ownerTag is empty, a unique per-instance tag is generated.

A NON-empty tag must be unique per process against the same registry: two loaders sharing one tag each reloadFromOwner their own partition on every rescan and each clearOwner in their destructor, so they mutually wipe each other's entries. (Every in-tree tag is a distinct constant.)

~ProfileLoader()

PhosphorAnimation::ProfileLoader::~ProfileLoader ( )

override

Member Function Documentation

entries()

QList< Entry > PhosphorAnimation::ProfileLoader::entries

(

)

const

loadFromDirectories()

int PhosphorAnimation::ProfileLoader::loadFromDirectories	(	const QStringList &	directories,
		LiveReload	liveReload = LiveReload::Off,
		PhosphorFsLoader::RegistrationOrder	order = PhosphorFsLoader::RegistrationOrder::LowestPriorityFirst
	)

Scan multiple directories in caller-declared priority order.

loadFromDirectory()

int PhosphorAnimation::ProfileLoader::loadFromDirectory	(	const QString &	directory,
		LiveReload	liveReload = LiveReload::Off
	)

loadLibraryBuiltins()

int PhosphorAnimation::ProfileLoader::loadLibraryBuiltins

(

LiveReload

liveReload = LiveReload::Off

)

ownerTag()

QString PhosphorAnimation::ProfileLoader::ownerTag

(

)

const

profilesChanged

void PhosphorAnimation::ProfileLoader::profilesChanged ( )

signal

registeredCount()

int PhosphorAnimation::ProfileLoader::registeredCount

(

)

const

requestRescan()

void PhosphorAnimation::ProfileLoader::requestRescan

(

)

rescanNow()

void PhosphorAnimation::ProfileLoader::rescanNow

(

)

Rescan synchronously, so a caller that just wrote or deleted a profile file can read the registry back in the same call.

The debounced requestRescan would answer that read with the pre-write state.

GUI-thread only, like the rest of this class. Whatever the rescan emits, it emits on the CALLER's stack, so a caller that is mid-mutation fans out into every directly-connected listener before this returns.

Two independent predicates decide what that is. profilesChanged fires when THIS loader's tracked set or a parsed Profile value changed. Separately, the registry emits a per-path profileChanged for each entry ITS diff moved, plus at most one ownerReloaded — and neither when that diff is empty, i.e. when the batch neither adds nor removes anything this loader owns. The two can each fire without the other.

Unlike requestRescan, this does NOT defer when a scan is already running, and nothing bounds the recursion: calling it from one of those handlers re-enters the scan, and a handler that calls it unconditionally recurses for as long as each scan keeps finding a change. The caller owns termination.

---

The documentation for this class was generated from the following file:

• phosphor-animation/include/PhosphorAnimation/ProfileLoader.h