Skip to content

NAP 0.5.2

Compare
Choose a tag to compare
@cklosters cklosters released this 25 Jul 08:05
· 1668 commits to main since this release

Minor release that introduces a couple of new features, improvements and general bug fixes.

Download

New Features

Grouping

Group together resources of a specific type with the nap::Group<T>. Use Napkin to to create and author groups:

napkin_grouping

Grouping in NAP

  • There is currently 1 catch all group: ResourceGroup. This group can have any type of nap::Resource as member.
  • Adding an existing item to a group does not break your app structure
  • Groups can be nested inside other groups of the same group type. This allows you to build group hierarchies.
  • Define your own group, that holds members of a specific type, using the DEFINE_GROUP macro.
    • Automatically recognized by Napkin as a new group type.
  • Groups internally use nap::ResourcePtr, ensuring groups work in combination with hot-reloading.
  • Find an object in a group using nap::Group<T>::findObject() and nap::Group<T>::findObject<M>()

Grouping in Napkin

  • Allows you to create and edit groups of type nap::IGroup (as seen in the example GIF)
    • Uses RTTR to figure out what type of items the group can hold
  • Move items to a different group, if that group supports holding that item
  • Move items from group to group (reparent)
  • Reparent a group under another group
  • Remove an item or group from a group
  • Create and add new items to a group
  • Delete groups and all children in that group
  • Link to groups and child groups from existing resources and components

Sequencer

Resize Track Height:

sequencer_resizing

  • start & stop playback using the spacebar
  • ability to select segments and save/load them as presets into tracks, presets are saved in sequencer/presets folder
  • ability to resize trackheight
  • remove vertical zoom
  • tan point handlers are now zoom level independent, making them better manageable at greater zoom levels
  • reformatted all sequencer related code to make style consistent
  • added minimize / extend button above inspector
  • replaced all maps containing member function pointers with maps contain std::function<...> and lambdas
  • segments can have names

Improvements

Napkin Optimizations

During the process of implementing groups we optimized a lot of procedures in Napkin, smashed numerous bugs, optimized various code paths, removed dynamic_cast & fixed the ordering and display of entities and components. These changes apply to the data model and resource panel.

Misc

Fixes

Third Party

Updating pybind to pybind11-2.9.2

Deprecation

macOS

Unfortunately, after a lot of internal debate, we decided to deprecate macOS as an official NAP target. This means that from version 0.5.2 we will no longer actively develop or support macOS. CMake will issue the following warning if you build NAP from source on macOS:

CMake Deprecation Warning at CMakeLists.txt:60 (message):
[01:32:26]	[Step 2/2]   macOS (as a target) is no longer in active development or supported
[01:32:26]	[Step 2/2] 
[01:32:26]	[Step 2/2] 
[01:32:26]	[Step 2/2] -- NAP version: 0.5.2

We will continue to compile, test and validate the current x86-64 macOS (Catalina) build until it breaks, but that’s pretty much it. We will not update and maintain the macOS third party dependencies, support newer versions of macOS or add support for the M1.

That said: we encourage passionate MAC users to contribute, maybe even take over maintenance. There has been some effort already. We’re not planning on removing the macOS directives from the build system so supporting it remains completely possible.

Why? This is not because we don’t like the hardware, but because of the continuous tightening of restrictions of macOS, including: aggressive gate-keeping, required app singing, forcing specific data structures upon developers and vague, forever changing and breaking , requirements and policies. It’s simply not in line with our policies and what we stand for and goes against the FOSS mindset that NAP embraces.

We cannot sign the binaries and expect our users to do the same, subsequently, we cannot present our clients with apps that Apple flags as ‘damaged’, even if the application runs completely fine. We tried to work around & implement features to tackle these requirements but in doing so we wasted valuable time, time we’d like to spend on new features and general improvements. The problem is not only that requirements change from macOS release to release, but figuring out what those changes entail and how to properly address them is often poorly documented (looking at you code signing!). Trust me, it’s a # time sink. Especially for larger platforms. For these reasons it’s time to say goodbye to Apple and focus on platforms that don’t get in our way and let us do our job.

Apple, here’s a thought: Instead of making the life of developers more difficult, consider making it more fun.

Python

Python integration using Pybind is now disabled by default, unless enabled explicitly by specifying the -p or --enable-python flag. This flag is available when generating a solution, building a project or packaging nap from source. Why? Support for python has never been implemented 'properly'. We don't use it in production and we (unfortunately) don't have the time to properly support it. Pybind is currently directly integrated into our RTTI system and only partially exposed, which in turn creates a non uniform python interface. We therefore decided to officially drop support and deprecate the feature. When a user enables python the following deprecation message is logged by CMAKE:

CMake Deprecation Warning at CMakeLists.txt:60 (message):
  Python is no longer officially supported