I am not completely sure if this really makes sense: JSON and XML are human-readable formats commonly used by lots of applications. Plist files are in some binary format which requires further conversion to make use of it inside DB4S and has more or less rather specific use cases.

Plist files are in some binary format

Oh, .plist files don't have to be in binary format. They have a text representation too, and there are macOS utilities to convert between them.

I kind of wonder if we should have some kind of file detection logic (similar to file on *nix) that could detect a file type and potentially run the OS associated action for that file type. Maybe like mine types?

Our formats extension is able to decode binary Plist. You can use it as a display format. See #1716. As with any display format, editing is not supported, though.

@mgrojo Thanks for sharing that. I did some searching around and hadn't found that functionality.

It seems that there is an issue with that extension though. on 3.13.1 it seems that the extensions were compiled for Arm in the Intel package. I am on an Intel Macbook with Sequoia 15.0. App installed and updated with homebrew.

I got a sneak at the functionality in 3.12.2 before I realized I didn't have the latest. Now it gives this error when I try to load the extension manually or have it loaded automatically in settings.

@lucydodo maybe this is something you can sort out?

It looks like a relatively easy fix in the build script if I am understanding correctly - still kinda new to github actions. The extension build looks to be only building for the architecture the github runner is (guessing its arm). I was gonna fork and test this, but the workflows are intertwined and I can't get them to run in my fork as a test on the builds.

So this section:

might get fixed like this:

name: Build Extension
run: clang -I /opt/homebrew/opt/sqlb-sqlite/include -L /opt/homebrew/opt/sqlb-sqlite/lib -fno-common -dynamiclib src/extensions/extension-formats.c -arch arm64 -arch x86_64 -o extension-formats.dylib

Cool. Yeah @lucydodo will definitely be interested in investigating, and that'll likely help heaps. 😄

now that I know this capability and structure, I am working on a couple things to submit in, such as a plist-to-json function.

plist data raw:

existing plist to xml:

new plist to json (auto-detected):

this plist is an example of further 'encoding' needing to be deserialized, so i am working on another function to see about doing that.

I am also trying to add in some functionality where these extensions can share a list of display formats that can be added to the format drop down rather than having to manipulate these manually into place. since its in the core, i have to build to test the changes.

I am having trouble with doing a build though, so I am wondering if it is because of me trying to build on an intel mac rather than arm. i tried following the building.md doc but it seems to not be fully aligned with the CI builds in build_macos.yml so I am using that as a template instead. I cannot install the packages from the sqlitebrowser tap because they all require arm platform. this is why I wonder if I need those specific packages to build as the standard packages I have installed from homebrew give me these errors:

sqlitebrowser/src/sqlitedb.cpp:2146:5: error: use of undeclared identifier 'sqlite3_enable_load_extension'
 2146 |     sqlite3_enable_load_extension(_db, 1);
      |     ^
/sqlitebrowser/src/sqlitedb.cpp:2150:18: error: use of undeclared identifier 'sqlite3_load_extension'
 2150 |     int result = sqlite3_load_extension(_db, filePath.toUtf8(), nullptr, &error);
      |                  ^
/sqlitebrowser/src/sqlitedb.cpp:2155:9: error: use of undeclared identifier 'sqlite3_enable_load_extension'
 2155 |         sqlite3_enable_load_extension(_db, 0);
      |         ^
/sqlitebrowser/src/sqlitedb.cpp:2173:5: error: use of undeclared identifier 'sqlite3_enable_load_extension'
 2173 |     sqlite3_enable_load_extension(_db, Settings::getValue("extensions", "enable_load_extension").toBool());
      |     ^
4 errors generated.

here is the command I am using to build

mkdir build
cd build
cmake -G Ninja \
  -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_CXX_STANDARD=14 \
  -DCMAKE_PREFIX_PATH=$(brew --prefix qt@5) \
  -DENABLE_TESTING=ON \
  -DENABLE_LOAD_EXTENSION=ON \
  -Dsqlcipher=0 \
  .. && ninja

not fully related to the initial issue submission, but any thoughts here? should i open a new issue?

Oops, I forgot about this extension when transitioning to the universal binary. I'm sorry about that.
I'll have some free time this evening, so I'll add support for this extension then. :)

Hi @JamesHabben,
When building DB4S for macOS, the SQLite used is provided by the homebrew-tap, and it can be built through it.
However, as you mentioned, our current homebrew-tap does not support x86_64 machines.

If necessary, you can build SQLite yourself using the following set of commands:

curl -O https://www.sqlite.org/2024/sqlite-autoconf-3460100.tar.gz
tar -xvf sqlite-autoconf-3460100.tar.gz && cd sqlite-autoconf-3460100
export CPPFLAGS="-DSQLITE_ENABLE_API_ARMOR=1 -DSQLITE_ENABLE_COLUMN_METADATA=1 -DSQLITE_ENABLE_DBSTAT_VTAB=1 -DSQLITE_ENABLE_FTS3=1 -DSQLITE_ENABLE_FTS3_PARENTHESIS=1 -DSQLITE_ENABLE_FTS5=1 -DSQLITE_ENABLE_GEOPOLY=1 -DSQLITE_ENABLE_JSON1=1 -DSQLITE_ENABLE_MATH_FUNCTIONS=1 -DSQLITE_ENABLE_MEMORY_MANAGEMENT=1 -DSQLITE_ENABLE_RTREE=1 -DSQLITE_ENABLE_SNAPSHOT=1 -DSQLITE_ENABLE_SOUNDEX=1 -DSQLITE_ENABLE_STAT4=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -DSQLITE_MAX_ATTACHED=125 -DSQLITE_MAX_VARIABLE_NUMBER=250000 -DSQLITE_USE_URI=1"
./configure --prefix=[PREFIX_TO_INSTALL]  --disable-dependency-tracking --enable-dynamic-extensions --disable-readline --disable-editline
make && make install

And when executing the cmake command, provide the prefix path specified above in the CMAKE_PREFIX_PATH.
Free free to let me know anytime if you need more detailed assistance.

Hi @JamesHabben,

Support for the x86_64 architecture has been added. You can check it in continuous builds or nightly builds.

Just got the continuous build. Confirmed the error is gone and the plist() function is working.

Awesome! Ok, lets close this issue an we can follow up the plist PR stuff in the PR itself.

Good work both everyone! 😁

sounds good and thanks for the quick response and help.