cross-posted from: https://lemmy.ml/post/31443045

This is a port of @SleeplessOne1917@lemmy.ml 's library for rust:

https://github.com/SleeplessOne1917/pretty-num

I am very happy that jetbrains seem to support kotlin outside of intelliJ. Since I do not like IntelliJ that much, I might be able to use kotlin in other editors with good support too.

cross-posted from: https://lemm.ee/post/64557471

cross-posted from: https://lemmy.ml/post/21390036

I finished reading the Kotlin documentation (§Concepts) and want to do something now. I was thinking about making a desktop app with a GUI. For that people seem to recommend Jetbrains Compose.

It seems however that the guides (https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-multiplatform-create-first-app.html) to set up such a project assume I have more than one target. I however don't and thus don't need to divide my project into common code, ios code, wasm code, etc. I only need to compile my project for the JVM, since I'm only intending to support Linux and BSD. I don't have much experience with the Java/Kotlin-centric build systems and I would like to avoid investing too much time into it (since for now I would like to spend more time writing that app, preferring to learn Gradle later in my journey), so I thought about just generating a template as recommended by the guides (using https://kmp.jetbrains.com/) and to just remove everything that doesn't matter for my project. However, since I don't have much experience with Gradle yet, I don't know what exactly the changes are that I need to make to the build script

Generated code

import org.jetbrains.compose.desktop.application.dsl.TargetFormat

plugins {
    alias(libs.plugins.kotlinMultiplatform)
    alias(libs.plugins.jetbrainsCompose)
    alias(libs.plugins.compose.compiler)
}

kotlin {
    jvm("desktop")
    
    sourceSets {
        val desktopMain by getting
        
        commonMain.dependencies {
            implementation(compose.runtime)
            implementation(compose.foundation)
            implementation(compose.material)
            implementation(compose.ui)
            implementation(compose.components.resources)
            implementation(compose.components.uiToolingPreview)
            implementation(libs.androidx.lifecycle.viewmodel)
            implementation(libs.androidx.lifecycle.runtime.compose)
        }
        desktopMain.dependencies {
            implementation(compose.desktop.currentOs)
            implementation(libs.kotlinx.coroutines.swing)
        }
    }
}


compose.desktop {
    application {
        mainClass = "org.example.project.MainKt"

        nativeDistributions {
            targetFormats(TargetFormat.Dmg, TargetFormat.Msi, TargetFormat.Deb)
            packageName = "org.example.project"
            packageVersion = "1.0.0"
        }
    }
}

What resources should I look at to quickly create a kotlin Compose project targeting only the JVM? (maybe a gradle crashcourse????)

Unrelated, but if you want you can also share your opinion regarding the use of Compose vs JavaFX vs Swing for this situation

Source: https://toggl.com/blog/programming-languages-games?ref=dailydev

Hey everyone,

I'm excited to share iCore, a new library designed to streamline Android application development with modular and reusable components. iCore supports the MVVM architecture and provides base classes, extension functions, and various utility classes to reduce code duplication and speed up the development process.

Key Features:

• Reducing Code Duplication: By abstracting commonly used operations, it prevents the writing of repetitive code.

• Quick Start: With ready-to-use core components, it allows for a quick start to projects.

• Easy Integration: Easily integrates common operations like Retrofit, LiveData observation, and theme/language selection.

• Reactive Data Management with Kotlin Flow and LiveData: iCore manages asynchronous data streams using Kotlin Flow and handles UI updates with LiveData, offering a more reactive and modern data processing model.

• Extensive Extensions: Its extensible structure allows for customization according to application needs.

• Centralized Management: Provides centralized management by allowing easy access to application resources with ResourceProvider.

Links:

🔗 GitHub: iCore on GitHub

🔗 JitPack: iCore on JitPack

I'm looking forward to your feedback and contributions. Happy coding!

Changelog

v1.24.4 - 2024-06-24 - Flat Sun

Focus in this release has been on improving and refactoring frontend code, adding UI features such as column and row hiding and locking through Visibility and Position meta classes. Other UI related features, such as supporting the height and width of individual cells have also been implemented, allowing for column and row span functionality.

Additional frontend changes include adding a marker, which allows cells to be selected and improves the way input is passed on to underlying UI cell content. This allows for better widget and chart functionality among other improvements for code that wishes to extend the frontend functionality.

Finally, a more flexible approach is now supported around providing custom HTML/CSS/JS allowing for alternative styling and other such changes to the frontend rendering. Two view configs are provided out of the box to illustrate this, the compact and the spacious, with compact being the default choice when using show(..).

It is expected that this will be the final alpha release of v1.

Added

• Add a cell marker, allowing cells to be selected with input passed to underlying cell content
• Add functionality to position columns to the left or right and rows to the top or bottom
• Add functionality to hide columns and rows
• Add support for custom UI config with custom HTML/CSS/JS
• Implement cell height and width rendering when these are defined on cell

Fixed

• Nothing

Changed

• Rename init parameter to receiver for on(..) functions and process to processor on related for improved API intuition
• Change HTML structure of cells, also harmonize this with column and row headers
• Update widgets and charts to work with frontend changes
• Various documentation updates relating to changes

Removed

• Nothing

I came across this post (and more like it) claiming extensions to be a good, or at least different, solution for mapping DTO's.

Are they though? Aren't DTO's supposed to be pure data objects? I've always been taught to seperate my mappings in special mapping services or mapping libraries like MapStruct and ModelMapper for implementing the good practice of "seperation of concerns".

So what about extensions?

I've had a long time fascination with Conway's Game of Life, and with the Sigbla APIs starting to stabilize I thought it would be fun to play around a bit and implement it as an example.

You can find the Conway example code here, and it should hopefully, even if you're unfamiliar with Sigbla, be fairly straight forward to understand.

It's using various core features, such as views, batching, transformers and cloning, with about 100 lines of code to get it all working. It's not really what I would envision Sigbla being used for, but it's a fun little example..

Looks like we have some extra support for Kotlin projects.

1. http4k
2. mockk

Each given $2,500 (which is chump change for a company like Target, but it's better than 0) from https://opencollective.com/target-tech