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

Hi everyone, I am learning kotlin as my first language(I have a bit of python knowledge mostly useless stuffs) I am following the android tutorial for kotlin and now I am 100% lost at the tip calculator in kotlin here. What should/could I do to improve my situation? Any recommend would help me a lot. Thank!

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

Cross-posted from: https://programming.dev/post/13516196

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 have a screen where I want a lazy-loading card of various items below some necessary information, all of which will scroll down. My initial approach was to nest the lazycolumn under the card which is nested under a Column with a calculated nested height based on the size of the calls list. However, I can't do that, and neither can I do the following.

@Composable
@Preview
fun mockup() {
    val calls = mutableStateListOf(Pair(1..418, 418 downTo 1))
    MaterialTheme {
        LazyColumn(Modifier.verticalScroll(rememberScrollState())) {
            item {
                Text("Text and some necessary UI elements")
                Slider(value = .418f, onValueChange = {})
            }
            Card(Modifier.fillMaxWidth()) {
                items(calls.asReversed()) {
                    Row {
                        Text(it.first.toString(), Modifier.fillMaxWidth(0.5f), fontWeight = FontWeight.Black)
                        Text(it.second.toString(), Modifier.fillMaxWidth(0.5f))
                    }
                }
            }
        }
    }
}

I found https://stackoverflow.com/questions/68182413/compose-lazylist-section-background, for which the only viable solution found was to hack a special composable widget so that when combined, it looks like a continuous card. Still, I want to see if there's a "proper way" of doing this...