WASMA

Installer

git clone https://github.com/Azencorporation/Wasma

cd Wasma

cargo build --release

Testing

cd Wasma/src/client

cargo bench

WM Compositor

The WASMA compositor provides hardware-accelerated window composition with support for advanced effects, transparency, and multi-monitor configurations. Each window source can be individually controlled and monitored.

Key capabilities include real-time window capture, composition pipeline customization, and fine-grained control over rendering behavior.

UI Frontend

The UI frontend layer provides a flexible interface for interacting with the WASMA system. Applications can specify their own window sources, define custom rendering pipelines, and integrate seamlessly with the compositor.

Window Control

Additionally, web-based window management and embedded remote viewer support are available. Management of a single network (singularity) or multiple network (multi) instances is possible.

Example Window Configuration

// WASMA IN operational configuration
uri_handling_op {
    multi_instances = true;
    singularity_instances = false;
    protocol_def : tor://127.0.0.1:80 // This is an example; the user can specify the desired IP block and port.
    domain_def : azccriminal.onion // This is also an example; if live streaming over the domain is required.
    uri_handling_window_appspef : file://server_request/request.manifest // Window permissions and distribution permissions can all be determined here. Limits per request and access to which window is allowed are determined here.
    uri_compilation_define : uri://compilation_server:90 // This specifies whether the window is runtime compilation or real-time compilation.
    #_END_BLOCK_DEFINE // Closing at the beginning of the block, separate things will be specified below
    
    uO:?? user_withed(*sysuser) // Those who want to drop root: sysroot
    rg0:?? groups_ewithed(*groups_insys) // Groups withed extension can be managed and specified via user
    r0:?? in_limited_scope:ip_base10 in_scoped_bylevel:50 in_request_withed:glx_renderer // Setting limits per render request, pixel loading or content limit via bylevel, another renderer can be specified instead of glx_renderer.
}

nonprof = false
cpu_withed { core_affinity_stat("cores:5") }; // Optional nonprof if true, it dynamically allocates cores to itself
gpu_withed { gpu_affinity_withed("vram_public_gen:2048MB") }; // Optional nonprof if true, it dynamically allocates cores to itself
#U_WITH_CTL // Necessary closing for screen output.

offline_handling_section {
    offline:1 // If 1, offline windows are allowed; if 0, offline windows are closed.
    uri_schema: uri://wasma.bin//protocol_offline; // Offline window activation
    uri_section_start : OFFLINE_LOCALHOST_STAT // Offline local network memory allocation
}

Core Features

Manifest System

Furthermore, with the .manifest, you will no longer have just the simple launcher logic of .desktop; you will be able to manage all resource usage, app URI, photos, and the basic window usage logic of the application.

Sample Manifest Format

The permission system can be defined within the manifest, or you can define application window permissions outside the manifest using source*. You can also use the default permission systems.

// When used in the manifest, files starting with [source] must be present; when used outside of [source], files starting with source* must be present. This can change depending on custom permission variables.
name = app.name
uri_appimg = file://usr/share/pixelevel/map/12x12.png *// image path
uri_shortcut = file://Desktop *// shortcut path
cpu_perception = 1 *// can be defined via GUI, so this number can be changed
cpu_affinity = perception { 100 resource_max : 10 } bitmax *"20" *// defined bitmax limit per core
cpu_core_serve = "1" affinity_default *// memory allocated for the server can be set dynamically if desired. "dynamic" usage is set according to affinity as default, but you can define it separately if you wish.
gpu_perp = "VRAM:allocation:size_bydefault = 1024" *// maximum GPU memory allocated for the application can be located instead of allocation "location" The value should be used, but you can directly allocate the memory based on an area to be allocated, but this is problematic, so allocation is recommended. The sizebydefault field determines the maximum usage, not by default, but by custom, sizebyinsection, sizebyprop, etc., directly from the table according to custom or prop.
gpu_using = "1024" { 100 resource_max : 15 } bitwidthed *"25" *// max usage and bitwidth
ram_using = "DDR5" "1024MB" "*cache_resolved:swaponline" *// RAM usage area is determined by default, but you can set the swap usage allocated for cache to online or offline if you don't want it.
ram_used_bitwidth = "1024MB" "bit_width : 15" *cache_resourceing : "20%" *// bit To determine RAM usage and cache resource usage per width, use the following commands:
uri_app_source = file://usr/bin/app *permission_check *POLICY_ENV *// policy set env app resource execution
uri_app_resource = file://local/bin/app,file//bin/app *// optional depending on different variations
permission_check = URI:PERMISSION_DEVEL://string : permission_devel *USER *// open to user-level permission development, i.e., directory path $HOME/$USE_CONFIG/permission_app/source is retrieved from env environments. If it is a variation such as permission_sys or permission_preset, permission_pinning, permission_purning, the directory paths are different.

WASMA-UBIN

With wasma-ubin, you will be able to add missing GTK/QT/ICED features by analyzing them through the binary file. Each platform will support certain features according to its own design limitations. Now you will be able to experience a full application theme widget experience with those features!

XDG-WSDG Conversion Support

xdg-wsdg conversion support: Now you can use a modern, advanced, fully customizable DG environment with wsdg. "You can also convert the xdg environment to wsdg without any problems in any application."

System Capabilities

• Full control over window rendering pipeline
• Hardware-accelerated composition
• Multi-monitor aware architecture
• Custom shader support for window effects
• Real-time performance metrics
• Plugin system for extensibility
• Cross-platform compatibility layer

API Reference

The WASMA API provides comprehensive access to all system features. Documentation includes detailed examples, best practices, and performance considerations for each API endpoint.

Permission System

The permission system can be defined within the manifest, or you can define application window permissions outside the manifest using source*. You can also use the default permission systems.

Example Permission Configuration

// When used in the manifest, files starting with [source] must be present; when used outside of [source], files starting with source* must be present. This can change depending on custom permission variables.
// Example directory paths
// permission_sys = $ROOT/lib/share/permission/source
// permission_pinning = $ROOT/lib/share/permissioner/source_pinning // Permissions are chattr; modification rights are possible if the user wishes.
// permission_purning = $ROOT/lib/share/permissionpurnering/source_purnering // Permissions are dynamic; each application is distributed with a small number of permissions. You may need to grant permissions later.
// Permission format depends on the applist, but
// USE_ETHERNET_CONNECTION = 1 // Ethernet connection usage application
// USE_WIFI_CONNECTION = 1 // Wi-Fi connection Usage of application
// USE_CHATTR_DISABLER = 0 // Should pinning be disabled if the application wants it or if you want it?
// USE_FILE_EXCEPTION = *file://Documents // Allow access only to a specific file area *&ALL // Access to all file areas is queried *file://* // Unqueried access
// USE_FILE_WITDH = 20 GB // Determine application width. By default, this is false because it can cause application problems and is often unnecessary.
// USE_WEB_RESOLVEING = http://brave.com // Specific web resolution resource, but with this feature, you only specify that the application can interact with a specific domain. The application interaction structure may be broken, so you can leave it as ALL_DEFAULT if you want.
// USE_USB_CONNECTIONAL = driver_disk_iot // Allows access to all USB drivers. *ALL_DRIVER: Allows access to specific drivers. driver_disk_iot: Allows access to disk-based USB drivers. driver_ethernet_usb_port: Allows access to Ethernet-based USB adapters. driver_usb_media: Allows access to media-based devices only. driver_usb_plug_and_play: Allows plug-and-play permissions.
// USE_USB_NET = 1 // Allows network access over USB. 0 access disabled, 1 access enabled.
// USE_USB_PLUG_AND_PLAY = ALL // Allows access to specific plug-and-play devices. For example, "microphone" allows access to microphone-based devices, "camera" allows access to USB camera modules, "mouse" allows access to mouse modules only, "midi" allows access to MIDI-based devices, "ALL" allows access to all devices. Access
// USE_WEBCAM_OPENED = &step_by_device = :use_webcam // To set webcam access when needed, use "use_webcam"; to set access in all cases, use "ALL" without step_by_device
// USE_MICROPHONE = ALL // Microphone access: One-time access "JUSTING"; access disabled "NO"; access always "ALL"
// USE_AUDIO = ALL // Audio access: One-time access "JUSTING"; access disabled "NO"; access when needed "OPENED_ALL"; access always "ALL"

For complete API documentation, refer to the developer guide and code examples in the WASMA repository.