Koncepto Sociala

What I have made during the summer

2026-07-12T00:00:00+00:00

Xide (Java, Kotlin): I've decided to replace RSyntaxTextArea completely (it takes much more time, but I guess it worth it), because it was primarily developed for conservative old school IDEs like eclipse, not really suitable for LSPs or tree sitter, so I am making editor from scratch, using Piece Table optimization. The next step will be text selection and syntax highlighting. I also added Kotlin support to my project and now all the plugins are or will be written in Kotlin. I am also still fighting with the style, I think that the previous version is too dark for every monitor, so I am sticking to GitHub Dark FlatLaf theme, looks nice (but not for ever :))

XastC (Haskell): Xast programming language compiler, now I am on semantic analysis stage – name resolution, import resolution, Hindley Milner type inference are implemented almost, but the hardest part is going further – many optimizations (CoW, unique types, compile time expressions, and so on, and so on....) as well as desugaring and maybe even more syntax sugar to make the language usable for big projects. Semantics are still in development.

XastGE (Rust): I fully replaced my half-OOP libGDX-like architecture with World storage, with fully ECS based approach - Flecs modules, systems and sometimes compiled queries. I also added simple UI (text rendering with automatic layout and tweening hover animations) and C Flecs shared .so plugins support, so I could later write my game logic in Xast, compiling it to C and using it as plugins for my engine. Now it is being developed and scaled much more naturally and easily!

Carol (former Java, now Vala): Yes, it is really strange idea to fully migrate from feature rich and big ecosystem language like Java, with libGDX framework to a language, which was made for GTK (Linux GUI toolkit) apps and has literally no game engines and frameworks... But it is really fun, because this language looks a lot like Java/C#, but is compiled to C, so, without GC (but sometimes with reference counting), VM, very fast compilation and near C performance. And it just looks fun. And also libGDX just broke my X11 WM because of, idk really what, but maybe old LWJGL version, used because of Nifty GUI (cool lib though). But nevertheless, I am not sure, when I'll continue developing this concrete game (I almost fully transferred it from Java to Vala), because I don't really know, what it must become, and what the story should be about, so... We'll see :)

MVU Pattern and Functional Approach in Flutter

2025-12-08T00:00:00+00:00

When learning Flutter, its view-state management is straightforward at first glance: you create your own widget classes and use anonymous functions as callbacks directly in the view, where you use built-in setState(...)</code> function to change a state inside this widget. But as the project grows, you can face some problems using this approach:
Synchronization of state and presentation. When you change some value in one place, which should change a presentation (view) in another place, when your widget depends on another widget's state, when and how should you call your setState(...)</code>? </li> Correct event handling. When some event happens in one widget, how would you handle execution of the next one? And moreover, if the next event should happen in another widget, and even more is async</code>, how will you preserve the execution order? </li> Multiple widgets — multiple states. If one widget's state depends on another one, for example, some page's state depends on the root widget's state or even on another page, how will you synchronize it? Borrowing mutable references of a widget state or a part of it is the most common approach in Flutter, because objects are passed by mutable references there. For example, borrowing Post</code>s from some Blog</code> page for each PostPreview</code> widget, so every PostPreview</code> will contain a reference to its corresponding post. But it's really error-prone in big projects with a lot of widgets and states, see the points above. </li> </ol> It is not the only Flutter's problem, a lot of frameworks, which are worse designed, are even harder to handle. However, there is a quite simple solution, which would work well even on big projects and is well presented in the Elm framework and programming language — MVU pattern, along with some functional approach, which will make your project even less error-prone. What is MVU?</h2> MVU (acronym for Model-View-Update) is a simple pattern which uses the simple algorithm: We have an initial model, a global collection of data, used in our application, which we initialize at the beginning of the program. If its structure becomes too big, we can split it into modules, as it's done in Elm. </li> We have our view — a root widget, which is built from smaller widgets which we can interact with. </li> When we interact with our view, e.g. clicking button, writing text etc., we send some Msg</code> — "tagged union"-based event data structure, which is then processed in a special update</code> function, that will return a new version of our model and build a new view with respect to the new model. </li> </ol> Advantages of this approach are obvious: we don't care about state management at all, we just send a specific Msg</code> for each specific action and process it in an update</code> function, changing the model, which automatically updates the view as needed. And the most pleasant is the thing, that we can easily implement it in Flutter, without difficult project architecture, and I'll show you how. Let's go! Simple and pure counter project</h2> Like most UI frameworks tutorials, and especially MVU-based ones, we will start with a simple counter project. I call it pure, because for now our application logic will not contain any side effects and will only affect the inner state of a program: increment/decrement a number. Firstly, we need to create our main MVU</code> widget, which will be a skeleton for our program. Let's create some auxiliary types and an MVU</code> class: typedef Update<M, Msg> = M Function(M model, Msg msg); typedef View<M, Msg> = Widget Function( M model, void Function(Msg msg) dispatch, ); class MVU<M, Msg> extends StatefulWidget { final M initialModel; final Update<M, Msg> update; final View<M, Msg> view; const MVU({ super.key, required this.initialModel, required this.update, required this.view, }); @override MVUState<M, Msg> createState() => MVUState<M, Msg>(); } // Here we change our state based on the dispatched Msg class MVUState<M, Msg> extends State<MVU<M, Msg>> { late M model; @override void initState() { super.initState(); model = widget.initialModel; } void dispatch(Msg msg) { final newModel = widget.update(model, msg); setState(() { model = newModel; }); } @override Widget build(BuildContext context) { return widget.view(model, dispatch); } }</code></pre> Now we will create our Model</code> and Msg</code>. Because the first is immutable, and the second is actually an ADT, we will use freezed</code> package for this. import 'package:freezed_annotation/freezed_annotation.dart'; part 'model.freezed.dart'; @freezed abstract class Model with _$Model { const Model._(); // Declare our fields here const factory Model({ required int value }) = _Model; // Initial state factory Model.initial() => Model( value: 0 ); }</code></pre>import 'package:flutter/foundation.dart'; import 'package:freezed_annotation/freezed_annotation.dart'; part 'msg.freezed.dart'; @freezed sealed class Msg with _$Msg { const factory Msg.increment() = Increment; const factory Msg.decrement() = Decrement; }</code></pre> Variants of our Msg</code> can also have fields, so we can pass some data sending events, but for our application it is not needed. Also, do not forget to add build_runner</code> package to dependencies and run dart run build_runner watch -d</code> to generate freezed files. Then we initialize our application and main widget, containing the MVU</code>: void main() => runApp(const AppRoot()); class AppRoot extends StatelessWidget { const AppRoot({super.key}); @override Widget build(BuildContext context) => MVU<Model, Msg>( initialModel: Model.initial(), update: update, view: view, ); }</code></pre> In the update</code> function, we will process our events, which are dispatched in UI. In our application it is simple for now (and pure): Model update(Model model, Msg msg) => switch (msg) { // Copying immutable models in `freezed` // is actually cheap, unlike deep cloning Increment() => model.copyWith(value: model.value + 1), Decrement() => model.copyWith(value: model.value - 1), };</code></pre> And in view</code> we will initialize our UI, which will be based on our Model</code> and could dispatch events with Msg</code>: Widget view(Model model, void Function(Msg) dispatch) => MaterialApp( // General stuff debugShowCheckedModeBanner: false, title: 'Counter MVU', theme: ThemeData.light(), home: Scaffold( body: Row( mainAxisAlignment: MainAxisAlignment.center, crossAxisAlignment: CrossAxisAlignment.center, children: [ // This button dispatches `Increment` event TextButton( onPressed: () => dispatch(Increment()), child: Text('Increment'), ), // Here we print value from the model Text('Value: ${model.value}'), // This button dispatches `Decrement` event TextButton( onPressed: () => dispatch(Decrement()), child: Text('Decrement'), ), ], ), ) );</code></pre> And that's it! Now we have a pure MVU-idiomatic counter application, which we can easily extend and maintain, as each event the application sends, can and must be processed explicitly. MVU with nested widgets</h2> However, as the project grows, we create new widgets which don't have direct access to our MVUState</code> and dispatch</code> function. How to deal with it? The answer is clear and quite Dart'ish: we just create anonymous functions, which enclosure dispatch calls for every needed Msg</code> and then pass them to our widgets' constructors, so we can call them from there. In our example, we will separate buttons into different widgets; it's not very good to do this, as they are semantically similar, but it's for an educational purpose 😊 Create two simple classes: class IncButton extends StatelessWidget { final VoidCallback onIncrement; const IncButton({super.key, required this.onIncrement}); @override Widget build(BuildContext context) => TextButton( onPressed: onIncrement, child: Text('Increment'), ); } class DecButton extends StatelessWidget { final VoidCallback onDecrement; const DecButton({super.key, required this.onDecrement}); @override Widget build(BuildContext context) => TextButton( onPressed: onDecrement, child: Text('Increment'), ); }</code></pre> And pass anonymous function with a correct dispatch</code>: ... children: [ IncButton(onIncrement: () => dispatch(Increment())), Text('Value: ${model.value}'), DecButton(onDecrement: () => dispatch(Decrement())), ] ...</code></pre>Side effects and async</h2> But what if we want some side effects to occur, when processing our events: reading from file, printing to terminal, web requests etc.? If they are synced, we could just rewrite our update</code> function imperatively and use side effects implicitly. However, the better way would be to use IO</code> wrapper to explicitly show that our event can have side effects. And even better Task</code> wrapper, because most Flutter side effects are async, so that it won't freeze our UI. So to introduce side effects in our MVU pattern, let's first change the signature of our Update</code> type alias: // Semantically means: returns `Task`, that processes model M typedef Update<M, Msg> = Task<M> Function(M model, Msg msg);</code></pre> and dispatch method inside MVU</code> widget: // Changed to async context void dispatch(Msg msg) async { // Added .run() to execute `Task` final newModel = await widget.update(model, msg).run(); setState(() { model = newModel; }); }</code></pre> For example, let's add some side effects to the Increment</code> event to save some data using SharedPreferences</code>. For this we should add a new variant SaveData(int data)</code> to Msg</code> and use Task</code> or Task.Do</code> (which is actually more useful in TaskEither.Do). To evoke an event from another event, we can simply call the update</code> function with the new model and the needed Msg</code>. But in the Task</code> context, it is more interesting: // We return Task instead of a raw Model Task<Model> update(Model model, Msg msg) => switch (msg) { Increment() => Task.Do( ($) async { // Compute a new model final newModel = model.copyWith(value: model.value + 1); // Return the result of the `SaveData` event with `$` // (we will talk about `$` later) return $(update(newModel, SaveData(model.value))); } ), Decrement() => Task.of(model.copyWith(value: model.value - 1)), SaveData(:final data) => Task.Do( ($) async { // Do some async stuff final pref = await SharedPreferences.getInstance(); await pref.setInt("counter", data); // Return model as is, because we haven't done any computation here return model; } ) };</code></pre> You might notice that the Do</code> and the $</code> operator are implementation of the monad do-notation</code> borrowed from Haskell: Do</code> is a syntax sugar to present monad consecutive computation in a imperative way;</li> $</code> is actually a function which is almost an analogue of the <-</code> operator in Haskell: it "unwraps" a context, some mysterious box, where the value is hidden, and returns it, if it is available, to continue computation. With a Task</code> semantics, it is like: "if the value is computed asynchronously — get it and pass forward, if not yet — wait, if it is failed — stop computation." We will discuss this stuff below.</li> </ul> More functional features: Option, Either, TaskEither</h2> The $</code> operator is more useful and, what is more important, understandable in contexts like Option</code> — context with "optional value" semantics or Either</code> — context with "value or error" semantics. For example, say we have two functions: one, which returns a reciprocal of a number, and another, which returns a square root. First of all, how do we handle situations where these functions are not defined? We can do it implicitly by throwing an exception, but we should specify all error cases in documentation, which not everyone does. Also, we can return something like -1</code> value, but, again, without proper documentation it can still cause a lot of errors. In Flutter, we can return a nullable type, and it is better. fpdart</code>'s Option</code> type is the same as nullable, but with the possibility to be used in consecutive (monadic) computations. Let's write these functions: Option<double> reciprocal(double n) { if (n == 0) { return None(); } return Some(1 / n); } Option<double> root(double n) { if (n < 0) { return None(); } return Some(sqrt(n)); }</code></pre> Or in more functional way using pattern matching: Option<double> reciprocal(double n) => switch (n) { 0 => None(), _ => Some(1 / n), }; Option<double> root(double n) => switch (n) { final invalid when invalid < 0 => None(), final other => Some(sqrt(other)) };</code></pre> And then, what will be the composition of these functions? Obviously, it is a "reciprocal root" of a number, but what would it look like in code? We can simply check the return value of each function like null-checking in Java: Option<double> reciprocalRoot(double n) { final x = root(n); if (x.isSome()) { final y = reciprocal(x.toNullable()!); return y; } else { return None(); } }</code></pre> But what if we had 10 optional computations, how many nested brackets would we get? The question is rhetorical 😅 To avoid it, we can use an approach which we'd use in Rust dealing with consecutive Option</code>s — and_then</code>. While writing this post, I found out that fpdart</code> analogue of and_then</code> is flatMap</code>, while andThen</code> is a really different function, but whatever 😁 It would look like this: Option<double> reciprocalRoot(double n) => root(n) .flatMap((value) => reciprocal(value));</code></pre> Much better. Now even having multiple steps, everything will be linear, without nested brackets. But we can go even further — use a functional approach in an imperative way, even if it sounds paradoxical. This is where do-notation comes in. We can write our Option</code>-computations as a sequence of imperative commands, "unwrapping" values for the next computation using the previously defined $</code> operator: Option<double> reciprocalRoot(double n) => Option.Do( ($) { final x = $(root(n)); final y = $(reciprocal(x)); return y; } );</code></pre> or more simply, without a redundant binding: Option<double> reciprocalRoot(double n) => Option.Do( ($) { final x = $(root(n)); return $(reciprocal(x)); } );</code></pre> $</code> here does exactly the same as in a Task</code> case: "if a value exists — get it and pass it forward, otherwise — stop the computation". Either</code> is similar to Option</code>, but instead of None</code>, we can indicate some "erroneous" computation with a custom error type — String</code>, some ADT etc. TaskOption</code> and TaskEither</code> are async wrappers for optional and erroneous types which indicate: "this function describes an async computation with effects which may fail". This is really useful in handling consecutive web requests. Here are some examples from my Frago</a> project: one with do-notation: TaskEither<LoginError, String> pollForToken({ required String clientId, required String deviceCode, int interval = 5 }) => TaskEither.Do( ($) async { await Future.delayed(Duration(seconds: interval)); final accessTokenInfo = await $(accessToken( clientId: clientId, deviceCode: deviceCode )); return switch (accessTokenInfo) { Token(token: final token) => token, Error(err: final err) => switch (err) { AuthPending() => $(pollForToken( clientId: clientId, deviceCode: deviceCode )), ExpiredToken() => $(TaskEither.left( LoginError(kind: LoginErrorKind.expiredToken) )), ... } }; } );</code></pre> and one without it: TaskEither<LoginError, String> fetchGitHubUser(String token) => TaskEither .tryCatch( () async => await http.get( Uri.parse('https://api.github.com/user'), headers: { 'Authorization': 'token $token', 'Accept': 'application/vnd.github.v3+json', }, ), (_, __) => LoginError(kind: LoginErrorKind.cannotResolve), ) ... .map((data) => data['login']! as String);</code></pre>Conclusion</h2> The MVU pattern offers a refreshing alternative to the traditional, often tangled approaches to state management in Flutter. By centralizing state in an immutable model and routing every change through explicit messages and an update</code> function, MVU dramatically simplifies reasoning about how an application behaves. Instead of chasing setState</code> calls or synchronizing multiple widget states, you work with a predictable, linear data flow that scales naturally as your project grows. Introducing functional ideas like Task</code>, Option</code>, and Either</code> further strengthens this foundation. Side effects become explicit, async workflows become easier to follow, and error handling becomes intentional rather than accidental. These tools let you write code that not only works but clearly communicates what it does and why. Also, in this tutorial we used freezed</code> and fpdart</code> packages, however they are much more powerful than presented here, so you're welcome to visit their homepages for more info: fpdart</a></li> freezed</a></li> </ul>
Making a Static Blog in Elm: Why and How? 2025-08-21T00:00:00+00:00 Warning: this post is more like a cheat sheet than a full tutorial, so you should get acquainted with some basics of functional programming, or at least read the official Elm guide</a> first. I've been remaking my tech blog on GitHub Pages several times: I switched themes for Jekyll static website generator, then moved from Jekyll to Zola, wrote my own Zola theme</a>, returned to Jekyll back with a simple no-style design, but it was really boring. I still write my blog posts in plain old Markdown, as I did before, but I wanted to try something new and quite captivating; however, writing my own Jekyll/Zola theme from scratch seemed unsound, because it's still the same HTML/CSS/JS, which we all "love" so much. About a year ago I got acquainted with Elm. Then it seemed to me like another one "compile-to-JS" stuff, with a weird syntax, but still well-known and cool MVP paradigm, like in Flutter, Relm and other declarative UI frameworks. And now in 2025, when I got used to Haskell syntax as well as a functional programming paradigm, I clearly see Elm as a simplified version of Haskell (what it really is), developed for web frontend. And now this website, at least as of the 21st of August, 2025, is completely written in Elm, and I'll show you how exactly. Why?</h2> You should use Elm for building a website for several reasons: Strict static typing: no null</code>, undefined</code>, [] + {} - " "</code> expressions and other undebuggable stuff — only strong and concrete data types;</li> Cool functional features, like immutability, pattern matching, ADTs</a> etc;</li> Reactive and modern Model-View-Update architecture, which is fast and pretty easy to use for creating responsive applications (even a blog);</li> No JavaScript! You may use it only if you need some specific stuff, written in JS, which is not present in Elm infrastructure (like highlight.js; you can read about it below).</li> </ol> How?</h2> First of all, install Elm and make a basic web app setup, following this guide</a>. Now create base index.html</code> file with the following contents: <!DOCTYPE html> <html> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <link rel="stylesheet" href="/absolute/path/to/css"> <title></title> </head> <body> <script src="/elm.js"></script> <script> var app = Elm.Main.init(); </script> </body> </html></code></pre> Note: you should also copy your index.html</code> contents to 404.html</code> file as your server will redirect every page to a 404 default page, which would be useful to turn out to be a copy of the app's main page :) In this tutorial we won't use elm reactor</code>, because it can't work with html files and it will be hard to debug, imo. Instead, I'd recommend to install Run on Save VS Code extension</a> and write the following lines to your .vscode/settings.json</code>: { "emeraldwalk.runonsave": { "commands": [ { "match": "\\.(elm)$", "cmd": "elm make src/Main.elm --optimize --output=elm.js" } ] } }</code></pre> Now every time you save any of your Elm files, the project will be compiled to an elm.js</code> file and you will be able to test your app in your browser using some kind of HTTP server. I haven't come up with anything better than using a custom Python HTTP server, run with a simple script, which you can find on this pastebin link</a>, as I don't want to write the full code here. Now let's start coding in Elm! Start with Model</code> and Event</code> types, which are crucial in every Elm application: type alias Model msg = -- Navigation key used in URL change { key : Browser.Navigation.Key -- Route to navigate through our pages , route : Route -- Current page content to be loaded , currentPage : Maybe (Html msg) -- Current title to be loaded , currentTitle : Maybe (String) -- Loaded blog post previews (like date + title + link) , blogPosts : Maybe (List PostData) } -- Different events (predominantly for data loading) type Event = UrlChange Url | LinkClicked UrlRequest | PostLoaded (Result Http.Error String) | PostsIndexLoaded (Result Http.Error (List PostData)) -- Will be used for Highlight.js example | DomReady</code></pre> And let's write some simple routes parsing: type Route = Home | About | Blog | Post String | NotFound String routeParser : Parser (Route -> a) a routeParser = oneOf [ map Home top -- / , map About (s "about") -- /about , map Blog (s "blog") -- /blog , map Post (s "post" </> string) -- /post/my-super-post ] parseUrl : Url.Url -> Route parseUrl url = parse routeParser url |> Maybe.withDefault (NotFound (String.dropLeft 1 url.path))</code></pre> Now let's take a look at our main</code> function in Main.elm</code>: main : Program () (Model Event) Event main = Browser.application { init = init , view = \m -> { title = case m.currentTitle of Just title -> title Nothing -> "Loading..." , body = case m.currentPage of Just pageView -> [ pageView ] Nothing -> [ text "Loading..." ] } , update = update , subscriptions = always Sub.none , onUrlChange = UrlChange , onUrlRequest = LinkClicked }</code></pre> Let's highlight the most important moments: view</code> function: as we get a part of our views from HTTP requests, we can't just rely on static view for each route like "if home then view home", "if post then view post" etc. We will just try to show some results, stored in the Model, which will be computed in init</code> and update</code> functions;</li> init</code> function: there we will parse our passed URL, construct our initial Model with the data given and check the route to perform further actions: load view directly (Home, About) or send an HTTP request (Blog, Post). Here it is:init : () -> Url -> Nav.Key -> ( Model Event, Cmd Event ) init _ url key = -- Parse our url and generate initial model let route = parseUrl url model = { key = key , route = route , currentPage = Nothing , currentTitle = Nothing , blogPosts = Nothing } in case model.route of -- Load view directly Home -> ( { model | currentPage = Just (pageLayout model.route "Koncepto Sociala" Home.view) , currentTitle = Just "Koncepto Sociala" } , Cmd.none ) -- Send some HTTP request with a result returned as our Event Blog -> ( model , Http.get { url = "../posts/index.json" -- result will be parsed from JSON to our `List PostData` type , expect = Http.expectJson PostsIndexLoaded postListDecoder } ) -- Other routes</code></pre></li> update</code> function: here we will process all the events emitted:update : Event -> Model Event -> ( Model Event, Cmd Event ) update msg model = case msg of -- event matching</code></pre>UrlChange</code> and LinkClicked</code> are usual for most of Elm apps where manipulation with links happens:UrlChange url -> -- We call init for every URL change, as we need to parse it -- for every route and remove unnecessary data init () url model.key LinkClicked req -> case req of External href -> ( model, Nav.load href ) Internal url -> ( model, Nav.pushUrl model.key (Url.toString url) ) </code></pre>But let's also look at a more interesting event:-- Emitted, when a post loaded from HTTP request PostLoaded result -> case result of -- If it is actually loaded — we parse its content -- to our Post model using custom parser; -- for more info, look at a repo of this website (links are at the post footer) Ok content -> let post = Parser.run PostModel.parse content in case post of Ok p -> ( { model | currentPage = Just (pageLayout model.route p.name (Post.view p)) , currentTitle = Just p.name } -- What is this? We'll find out soon , nextTick DomReady ) -- Print errors, if parsing failed, for debug purposes Err errors -> ( { model | currentPage = Just (text ("Post parsing error:\n" ++ parsingErrors errors)) , currentTitle = Just "Post parsing error" } , Cmd.none ) -- Loading failed ;( Err _ -> ( { model | currentPage = Just (text "Post not found") , currentTitle = Just "Post not found" } , Cmd.none )</code></pre></li> </ol> Highlight.js or sync pitfalls</h2> What if we want to use some external JS library, which will process/change our DOM like Highlight.js? How shall we synchronize Elm, finishing generating our DOM, and our library, which must process it afterwards? Official documentation suggests, that we need ports — tool for interracting with some JavaScript code in Elm. Include needed libraries and change Elm initialization like this (don't forget to sync 404.html and index.html): // Init Elm app var app = Elm.Main.init(); // We will call hljs.highlightAll(); only when the message is sent app.ports.sendMessage.subscribe(function (message) { hljs.highlightAll(); });</code></pre> Then we rename our module</code> to port module</code> and add port sendMessage : () -> Cmd msg</code> to the top of our module, where events are processed. However, if you try to use sendMessage</code> directly, as suggested in official tutorials, you may find out, that Highlight.js works... but every other time. It happens because Highlight.js is still not really synchronized well and may be called before the DOM is completely generated. To avoid this behaviour, we will use our custom DomReady</code> event, which we prepared before, along with our custom nextTick</code> function to make a small delay before calling JavaScript (20 ms should be sufficient): nextTick : msg -> Cmd msg nextTick msg = Task.perform (\_ -> msg) (Process.sleep 20)</code></pre> Now, when we send nextTick DomReady</code> command every time, where our JS library should be called, we will wait for 20 ms and then push DomReady</code> event to the application, which will be processed in a following straightforward way: DomReady -> -- means: send request event for JavaScript call ( model, sendMessage () )</code></pre>What's next?</h2> In this post I've not covered all the topics, that would be useful for making your Elm blog or another application using Elm, so here is some utile resources and libraries to learn: This website full code</a> — nothing to say more: useful utilities for parsing, data types and functions to work with them;</li> elm-css</a> — using CSS styling directly in Elm code;</li> elm-parser</a> — writing parsers easily;</li> elm-ui</a> — UI design toolkit as alternative for HTML/CSS. Looks promising, but I don't quite understand it yet;</li> json</a> and http</a> libraries — mandatory for any web app.</li> </ol> If I missed something or made a mistake — don't hesitate and file an issue</a> :3 Loading 3D texture in Bevy 2025-05-27T00:00:00+00:00 To load an image into our app Bevy provides us with a custom Image</code> type. However, AssetServer</code> in Bevy (as of version 0.15) only supports 2D image loading for now, so we need to perhaps implement a custom 3D image asset loader. For our tutorial we will use png and jpeg raster image types, but you can also try to implement importing of raw MagicaVoxel data, e.g. using dot_vox</code> crate. Implementing Image3dLoader</h2> First, we'll define our voxel texture format, Bevy plugin and loader struct itself: // RGB for color, A - 1 for `active`, 0 for `inactive`. // // As optimization in ray tracing you can consider using 1 byte // texture format like R8Uint and use 0 value for `inactive` // and 1-255 values as color palette indices. pub const IMAGE_3D_FORMAT: TextureFormat = TextureFormat::Rgba8Uint; pub struct Image3dPlugin; // Use a plugin to register our asset loader impl Plugin for Image3dPlugin { fn build(&self, app: &mut App) { app.init_asset_loader::<Image3dLoader>(); } } #[derive(Default)] pub struct Image3dLoader;</code></pre> And our loader settings will look like this: #[derive(Serialize, Deserialize, Debug)] pub struct Image3dLoaderSettings { pub format: ImageFormatSetting, pub columns: u32, pub rows: u32, }</code></pre> It's important to note, that Bevy AssetServer</code> supports only 1 loader per file extension (or a bundle of extensions), but we need to use png and jpeg formats, which are already bound by default loader. The easiest approach is to add an extension prefix, e.g. .3d</code>. We'd also like to define image column and row count in a filename for quick import, like (NxM). So our filename template will be: <image_name>.(<N>x<M>).3d.png</code>. Now getting our loading settings from a file path is straightforward: impl Image3dLoaderSettings { pub fn from_path(path: impl AsRef<Path>) -> Result<Self, Image3dLoaderError> { // get "<image_name>.(<N>x<M>).3d" part from path let stem = format!("{:?}", path.as_ref().file_stem().unwrap_or_default()); Image3dLoaderSettings::from_str(&stem) } } // And implement `from_str` impl FromStr for Image3dLoaderSettings { type Err = Image3dLoaderError; fn from_str(s: &str) -> Result<Self, Self::Err> { let cols_rows = s // "(<cols>x<rows>)" .trim_matches('"') .trim_end_matches(".3d") .split('.') .next_back() .ok_or(Image3dLoaderError::FromStrError(s.to_owned()))? // "<cols>x<rows>" .trim_start_matches('(') .trim_end_matches(')') // ("<cols>", "<rows>") .split_once("x") .ok_or(Image3dLoaderError::FromStrError(s.to_owned()))?; let columns = cols_rows.0.parse::<u32>() .map_err(|_| Image3dLoaderError::FromStrError(s.to_owned()))?; let rows = cols_rows.1.parse::<u32>() .map_err(|_| Image3dLoaderError::FromStrError(s.to_owned()))?; Ok(Image3dLoaderSettings { columns, rows, ..Default::default() }) } }</code></pre> The last thing to consider before implementing Image3dLoader</code> is a custom error type which will handle all possible problems while loading our 3D image. We'll use thiserror</code> crate for simplicity: #[non_exhaustive] #[derive(Debug, Error)] pub enum Image3dLoaderError { #[error("Invalid columns number: {0}")] InvalidColumnsNumber(u32), #[error("Invalid rows number: {0}")] InvalidRowsNumber(u32), #[error("Guessed format is unknown and cannot be determined")] UnknownFormat, #[error("Unsupported native format: {0:?}")] InvalidNativeFormat(bevy::image::ImageFormat), #[error("Invalid extension: {0:?}")] InvalidExtension(Option<OsString>), #[error("Cannot load 3D image: {0}")] ImageError(#[from] image::ImageError), #[error("I/O error: {0} ({0:?})")] IoError(#[from] io::Error), #[error("Cannot convert path to 3D image settings: invalid string format {0}; expected <name>.(<columns>x<rows>).3d")] FromStrError(String), }</code></pre> Finally, fill our AssetLoader</code> trait implementation with required types and functions: impl AssetLoader for Image3dLoader { type Asset = Image; type Settings = Option<Image3dLoaderSettings>; type Error = Image3dLoaderError; fn extensions(&self) -> &[&str] { &[ "3d.png", "3d.jpg", "3d.jpeg", // Other image types if needed ] } async fn load( &self, reader: &mut dyn Reader, settings: &Self::Settings, load_context: &mut LoadContext<'_>, ) -> Result<Self::Asset, Self::Error> { // implementation later } }</code></pre> At first place, retrieve all loader settings: use ImageFormatSetting::*; // If settings are not provided, retrieve them from our file path let settings = match settings { Some(s) => s.clone(), None => Image3dLoaderSettings::from_path(load_context.path())?, }; // Check whether our row and column count is correct if settings.columns == 0 { return Err(Image3dLoaderError::InvalidColumnsNumber(settings.columns)); } if settings.rows == 0 { return Err(Image3dLoaderError::InvalidRowsNumber(settings.rows)); } // Read asset file to `Vec` let mut bytes = vec![]; reader.read_to_end(&mut bytes).await?; let ext = load_context.path() .extension() .map(|ext| ext.to_owned()) .ok_or(Image3dLoaderError::InvalidExtension(None))?; // Get image format to load: by extension, manually or by `magic guessing` let format = match settings.format { FromExtension => ImageFormat::from_extension(ext.clone()) .ok_or(Image3dLoaderError::InvalidExtension(Some(ext)))?, Format(f) => f .as_image_crate_format() .ok_or(Image3dLoaderError::InvalidNativeFormat(f))?, Guess => image::guess_format(&bytes) .map_err(|_| Image3dLoaderError::UnknownFormat)?, };</code></pre> Now we need to store our 3D data, retrieved from row-column aligned 2D image, to 1d bytes array, because all data is transfered to GPU bit-by-bit. This may sound complicated, but we can calculate each next pixel, pushed to 1d array, with a following simple formula: where c</code> and r</code> are current column and row accordingly, x</code> and y</code> are current tile coordinates and w</code> and h</code> are single tile width and height. The algorithm will look like this: // Load image with `image` crate using previously determined format let img = image::load_from_memory_with_format(&bytes, format)? .to_rgba8(); let bw = img.width(); let bh = img.height(); // Calculate single tile dimensions using previously determined // column and row size let w = bw / settings.columns; let h = bh / settings.rows; let mut data = vec![]; // Calculate each next pixel position for r in 0..settings.rows { for c in 0..settings.columns { for y in 0..h { for x in 0..w { let pixel = img.get_pixel(x + c * w, y + r * h); data.extend(pixel.0); } } } }</code></pre> And finally we create an Image</code> instance using a GPU texture descriptor: // Define image dimensions let size = Extent3d { width: w, height: h, depth_or_array_layers: settings.columns * settings.rows, }; let img = Image { texture_descriptor: TextureDescriptor { label: Some("image 3d"), size, // Change it, if you need mip-map optimizations mip_level_count: 1, sample_count: 1, dimension: TextureDimension::D3, format: IMAGE_3D_FORMAT, // Add other usages if needed usage: TextureUsages::TEXTURE_BINDING | TextureUsages::COPY_DST | TextureUsages::STORAGE_BINDING, view_formats: &[IMAGE_3D_FORMAT], }, data, asset_usage: RenderAssetUsages::all(), ..Default::default() }; // Return our loaded 3D image Ok(img)</code></pre> Let's test it! Just add an asset server to our system and load our image as an asset: fn system(asset_server: Res<AssetServer>) { let handle: Handle<Image> = asset_server.load("my_image.(5x2).3d.png"); }</code></pre>Conclusion</h2> In this post, we explored how to implement a custom 3D texture loader for Bevy by leveraging the asset pipeline and extending it to support 3D data stored in standard 2D image formats. By organizing our 3D data as tiled slices and parsing loader settings from filenames, we can efficiently import and use 3D textures in our Bevy projects. This approach opens up new possibilities for voxel rendering, volumetric effects, and custom texture workflows, even before native 3D texture support lands in Bevy. Happy experimenting!

Koncepto Sociala

What I have made during the summer

MVU Pattern and Functional Approach in Flutter

Making a Static Blog in Elm: Why and How?

Why?</h2> You should use Elm for building a website for several reasons:</p> Strict static typing: no null</code>, undefined</code>, [] + {} - " "</code> expressions and other undebuggable stuff — only strong and concrete data types;</li>

Loading 3D texture in Bevy